From FORRERJ@frl.orst.edu Tue Jan 03 10:53:15 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPCTw-0001FNC; Tue, 3 Jan 95 10:53 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA28656 for <HFSIG@tapr.org>; Tue, 3 Jan 1995 01:31:33 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 3 Jan 95 8:51:21 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 3 Jan 95 8:51:02 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 3 Jan 1995 08:50:59 PST8PDT
Subject:       HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <CA0CBB055C2@frl.orst.edu>

Hi All,

Trust you had a good holiday season - best wishes for 1995.

Apparently there were some problems with the listserver - hope it is 
working now.

Bob asked an interesting question: whether soft decision decoding 
with convolutional coding was as effective as linear block coding 
with interleaving. There is an interesting, though rather oldish, paper 
about this that you may find interesting:

"Effective Application of Forward-Acting Error-Control Coding to 
Multichannel HF Data Modems" by Pierce et. al. IEEE Trans. on COMM, 
Vol COM-18 (4), August 1970. pp 281-294.

This paper compares early multi-tone parallel modems over HF paths and looks 
at how different phase and frequency shift modulation formats perform in 
conjunction with various linear block, as well as, convolutional codes. It 
appears that some block codes (i.e. (23,12)) code with interleaving does as 
well as a convolutional code with the appropiate constraint length (very 
large), however, it is not a simple matter to engineer the coding scheme 
without regard to the modulation scheme - these things should be engineered 
to work together and not separate. This comparison was by live 
experiments over transcontinental as well as transatlantic HF paths, and is 
about as old as the work done by Watterson on the HF channel simulator.  

I still am looking for further information on the Fast Hadamard Transform 
(or the Fast Walsh Transform). If anyone can shed some light on this, it 
would be greatly appreciated.

73's

Johan Forrer, KC7WW





From k5yfw@k5yfw.ampr.org  Tue Jan 03 20:50:35 1995
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPLnV-0001N1C; Tue, 3 Jan 95 20:50 CST
Date: Tue, 03 Jan 95 20:34:06 CST
Message-Id: <2428@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:170] HF modulation
In-Reply-To: Your message of Thu, 29 Dec 94 21:34 CST
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Hi Gang,

Wanna see video of a 53 year old ham sledding down a 1000 ft hill on a
plastic sled?  Wanna see the old feller go bump...wanna see the old
feller's 2 1/2 year old granddaughter say "Owie Pappa?"  Sun Valley
(Ketchum?) will never be the same again.  And no one answered my call on
the 147.18 MHz Ketchem repeater.

Boooooooo!

In message <941226232538_70730.3472_CHK57-1@CompuServe.COM> Johan writes:
        [stuff deleted]
> I also did capture the simulated output waveform and was quite concerned
> after inspecting the plot  -  the presence of large spikes of significant
> magnitude (in some cases, some 10-15 dB over the RMS value). This
> situation will certainly introduce data errors if not addressed. It should be
> stressed
> that such a signal will sound like a noise burst - it has little or no melody
> associated with
> it, except for the bit synchronizing pre-ambles. 

        I heard a couple of Harris engineers talking about the problem
        once...I think they fixed it in there MIL-STD-188-110 modems 39
        tone modem.

        Boy does the signal ever sound like noise...as you tune across
        the signal the S meter will rise and fall and you will think you
        are just tuning a noisy frequency.

        You need a receiver capable of 10 Hz resolution to receive this
        modulation and if you're receiver (transceiver) dial/readout
        doesn't show 10 Hz steps, you will need to have a tuning
        indicator built into the software.

> 
> It ir my opinion, that after this initial analysis, that such a scheme may be
> quite doable on our present hardware. I have no doubt that, if signal synthesis
> and fast
> Fourier transform are performed on the DSP side,  there should be plenty of
> computing power in a modest PC to run the remainder of such a modem, even
> considering the computing demands for error coding. 

        Sounds good to me.

> 
> Hope you all enjoyed the holiday season. Trust that 1995 will hold
> the best in health peace for you. 

        Yep, my holidays were fun fun fun.  Spoiled my granddaughter
        again just to get back at my son.

73 & CUL,

Walt@home.2.nite

From dlmill@mtu.edu  Wed Jan 04 09:36:48 1995
Return-Path: <dlmill@mtu.edu>
Received: from mtu.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPXlW-0000i4C; Wed, 4 Jan 95 09:36 CST
Received: from [141.219.23.194] (techmac11.tech.mtu.edu [141.219.23.194]) by mtu.edu (8.6.9/8.6.9) with SMTP id KAA15878 for <hfsig@tapr.org>; Wed, 4 Jan 1995 10:36:37 -0500
Message-Id: <199501041536.KAA15878@mtu.edu>
X-Sender: dlmill@techsrv1.tech.mtu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 4 Jan 1995 10:36:17 -0500
To: hfsig@tapr.org
From: dlmill@mtu.edu (Dan Miller)
Subject: subscribe

Could someone please email me how to subscribe to this list?
Dan dlmill@mtu.edu


From shall@rain.org Wed Jan 04 11:09:49 1995
Return-Path: <shall@rain.org>
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPZDX-0000vrC; Wed, 4 Jan 95 11:09 CST
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AA17694 
	  for hfsig@tapr.org on Wed, 4 Jan 95 09:05:58 PST
Date: Wed, 4 Jan 1995 09:05:57 -0800 (PST)
From: Stephen Hall <shall@rain.org>
To: hfsig@tapr.org
Cc: hfsig@tapr.org
Subject: Re: [HFSIG:175] subscribe
In-Reply-To: <199501041536.KAA15878@mtu.edu>
Message-Id: <Pine.SUN.3.90.950104090343.17248A-100000@coyote.rain.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

As I've forgotten, I too would like this posted. I have some friend that 
would like to subscribe additionally.



On Wed, 4 Jan 1995, Dan Miller wrote:

> Could someone please email me how to subscribe to this list?
> Dan dlmill@mtu.edu
> 
> 
> 
From FORRERJ@frl.orst.edu Wed Jan 04 11:14:58 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPZIM-0000sSC; Wed, 4 Jan 95 11:14 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA03199 for <hfsig@tapr.org>; Wed, 4 Jan 1995 01:53:36 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 4 Jan 95 9:13:26 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 4 Jan 95 9:13:24 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 4 Jan 1995 09:13:17 PST8PDT
Subject:       Re: [HFSIG:176] Re: subscribe
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <CB92BCD39FA@frl.orst.edu>

Hi, 

Hope this helps.



---


Greetings from TAPR!  

TAPR can be reached via the Internet.  The Automated Information Server that
TAPR provides allows anyone to request information on TAPR, products,
newsletters, and lots of other files.  To find out more about this service,
send an e-mail message to listserv@tapr.org with the subject line "Request"
and the following text in the body of the message:

help                             (for a brief set of instructions)
index -all                       (for a list of all file by topic area)
list                             (for a list of TAPR Mail Groups)
get tapr taprinfo.txt            (or info on TAPR)

  In the above message example, "help" retrieves a brief set of instructions
for info, "index -all" retrieves a list of available files by topic and
"taprinfo.txt" retrieves a text file containing information on TAPR and what
TAPR is all about.  If you want to retrieve several text files with one
message, use a separate line for each "get filename" request.

-----

General Information:

     * Ever heard of a TNC ?

     * Interested in general packet radio information?

     * Interested in high-speed packet operations?

     * Interested in other types of digital communications?

     * Interested in experimenting or building kits?

     * Interested in keeping up-to-date on national digital and packet
       issues?

                Then you might be interested in TAPR!


Goals:

     % Support Research and Development efforts in the area of 
       amateur digital communications

     % Disseminate information on packet and digital communications

     % Provide affordable and useful kits for experimenters and hobbyists

     % Pursue and help advance the amateur art of communications through
       publications, meetings, and standards


History:

  If you have used a packet radio TNC, then you are already a part of TAPR
history.

  The TNC (Terminal Node Controller) project grew from a discussion in
October of 1981 at a meeting of the Tucson Chapter of the IEEE Computer
Society.  A week later, six of the attendees gathered and discussed the
feasibility of developing a Terminal Node Controller that would be complete
and available to amateurs at a modest cost. This was the genesis of TAPR.

  On June 26th 1982, Lyle Johnson, WA7GXD, and Den Connors, KD2S, initiated
a packet contact with the first TAPR unit.  The project progressed from
these first prototype units to the TNC-1 and then finally to the TNC-2 which
is now the basis for most amateur packet operations worldwide.

  TAPR was founded in 1982 as a national organization with interests in the
areas of packet and digital communications.  Today, TAPR continues as a
membership supported non-profit amateur research and development
organization.  TAPR currently has more than 2000 members, worldwide.  TAPR
continues to develop kits for the amateur community and is working actively
on publications and communications standards.


Membership:

  Membership in TAPR includes a subscription to the quarterly published
Packet Status Register newsletter.  PSR has been published since 1982 and is
recognized as an authoritative source for up-to-date user and technical
information on packet radio.  Much of the material in PSR is timeless.  Back
issues may be obtained from the TAPR office.  Membership in TAPR is $15 for
one year.  In Canada and Mexico membership is $18 and outside North America
they are $25.


             Join the amateur digital-revolution -- Join TAPR!

-----

Special Interest Groups

  TAPR maintains several SIGs in various areas.  To get the latest list of
SIG groups, send an e-mail message to listserv@tapr.org with the subject
line "Request" and the following text in the body of the message:

list                             (for list of mail groups on TAPR.ORG)
  
  To request the information on any mail group, send an e-mail message to
listserv@tapr.org and in the message text include:

information listname           (where listname is the name of the mail 
group)

  When you are ready to subscribe, send e-mail to listserv@tapr.org with the
following command in the message text:

subscribe <list> <your name>

  List should be the name of the mail list you want to join and Your Name
should be both your First and Last Name.

Current SIGs include:
    NETSIG         Regional Networking SIG
    BBSSIG         BBS SIG
    HFSIG          SIG on HF Digital Topics
    DSP            DSP Software Development Forum
    DSP-93         SIG for those that are building TAPR/AMSAT DSP-93 kits
    APRSSIG        SIG on APRS

-----

FTP users

  The TAPR Software Library is now available via anonymous FTP.  You can
access the library by ftp access to 'ftp.hereford.ampr.org' in the directory
pub/hamradio/tapr.  Login in as 'anonymous', with a password of
'your_account@internet_address'.

-----

Packet Raido and TAPR is on the World-Wide-Web!

The series is accesible through the Packet Radio Home Page at this
URL:
        http://bb.iu.net/infomotion/taprhome.html

        http://bb.iu.net/infomotion/pkthome.html

What's here?  A page of links (the Home Page), the TAPR Home Page, a page of
Packet Pioneers and Contacts, a hypertext packet primer and FAQ, and more.

Thanks to Howie, N2WX, President of Infomotion, for his support and 
invaluable
contributions of the TAPR page.

-------------------------------------------------------------------------

Tucson Amateur Packet Radio
8987-309 E. Tanque Verde Road #337
Tucson, AZ 85749-9399
817-383-0000 (Tuesday - Friday 9:00-11:00am, 3:00-5:00pm CT)
             (15:00-17:00, 21:00-23:00 UTC)
817-566-2544 FAX

Internet: TAPR@TAPR.ORG
-------------------------------------------------------------------------

From ericr@lan.vita.org Wed Jan 04 16:19:47 1995
Return-Path: <ericr@vita.org>
Received: from relay3.UU.NET by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPe3U-0001GVC; Wed, 4 Jan 95 16:19 CST
Received: from lan.vita.org by relay3.UU.NET with SMTP 
	id QQxxgz18265; Wed, 4 Jan 1995 17:19:35 -0500
Received: by lan.vita.org (5.64/PERFORMIX-0.9/08-16-92)
	id AA14653; Wed, 4 Jan 95 16:49:57 EST
Date: Wed, 4 Jan 1995 16:49:57 -0500 (EST)
From: Eric Rosenberg <ericr@lan.vita.org>
Subject: System Design In Africa 
To: hfsig@tapr.org
Message-Id: <Pine.3.89.9501041620.B14644-0100000@lan.vita.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


VITA, Volunteers in Technical Assistance, a non-profit development
organization based in Arlington, VA is looking for a qualified volunteer
consultant to design a terrestrial digital radio network in Guinea, west
Africa. 

VITA presently operates nine offices in Guinea, most of which are already 
connected by a voice (radio) network. 

The consultant will meet with the project staff at the Country Office in 
Conakry to determine their needs and requirements, and then travel to 
some (or all) of the field offices to perform a first-hand site survey.  
 
Upon returning home, the consultant will provide VITA with a written 
report outlining the system needs with respect to hardware and software, 
detail the network architecture, and make recommendations on equipment 
and software to be installed at a future date.  This is *not* an amateur 
radio network. Familiarity with amateur radio among the project staff in 
Guinea is, at best, slight.

The trip will last two weeks, and will begin in late January or early 
February.  VITA will be responsible for all costs and expenses related to 
this trip, but is not in a position to pay a professional fee. 

The consultant must have experience in the following areas: HF voice and 
digital communications; system and network design; familiarity with existing 
hardware and software; working knowledge of French; 

If you are interested or require additional information, please contact 
Eric Rosenberg at the e-mail address below.  


-------
Eric Rosenberg				
Volunteers In Technical Assistance	voice: +703-276-1800
1600 Wilson Blvd., Suite 500 		fax:   +703-243-1865
Arlington, VA  22209  USA 		ericr@vita.org


From gjones@tenet.edu Wed Jan 04 18:51:34 1995
Return-Path: <gjones@tenet.edu>
Received: from Leslie-Francis.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPgQO-0000xYC; Wed, 4 Jan 95 18:51 CST
Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.9/8.6.9) id SAA00858 for hfsig@tapr.org; Wed, 4 Jan 1995 18:51:32 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199501050051.SAA00858@Leslie-Francis.tenet.edu>
Subject: Re: [HFSIG:176] Re: subscribe
To: hfsig@tapr.org
Date: Wed, 4 Jan 1995 18:51:31 -0600 (CST)
In-Reply-To: <Pine.SUN.3.90.950104090343.17248A-100000@coyote.rain.org> from "Stephen Hall" at Jan 4, 95 11:11:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 397       

Send email to listserv@tapr.org

in the message, say

get tapr taprinfo.txt

Cheers - Greg

According to Stephen Hall:
> 
> As I've forgotten, I too would like this posted. I have some friend that 
> would like to subscribe additionally.
> 
> 
> 
> On Wed, 4 Jan 1995, Dan Miller wrote:
> 
> > Could someone please email me how to subscribe to this list?
> > Dan dlmill@mtu.edu
> > 
> > 
> > 
> 

From karn@qualcomm.com Wed Jan 04 20:57:14 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPiO0-0001QdC; Wed, 4 Jan 95 20:57 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA11090; Wed, 4 Jan 1995 18:29:09 -0800
Date: Wed, 4 Jan 1995 18:29:09 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501050229.SAA11090@servo.qualcomm.com>
To: FORRERJ@frl.orst.edu
CC: hfsig@tapr.org
In-reply-to: <B80FA331EF6@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:163] Re: Ideas for HF modulation and coding

>1) (ODFM) n-parallel carriers with orthoganal signaling. All carriers 
>are always present. Demodulation is performed by FFT's. It is obvious that
>the choice of the FFT size and sample rate have to just right otherwise we 
>will end up with an odd distribution of our carriers over the 
>frequency/phase bins. After this choice have been made, how do I use this 
>I/Q recovered data? I have some wild ideas, but would like to obtain 
>further input first.

Nothing says you have to demod this with an FFT, although that's one
way to do it. Once you determine carrier phase and symbol timing, you
just generate a bunch of local carrier references, multiply each by
the received signals, and integrate and dump or however you want to
do the matched filtering. Of course, if you pick the right numbers you
would make it easier to do this with an FFT.

>2) (Phil's method based on Welch functions) n-parallel tones with orthoganal 
>signaling. Only a small subset of carriers are present at a time - the
>different subset is selected from a Hamadard matrix. In a sense, 

Actually, except for one codeword of all zeros the orthogonal
functions all have 50% of their bits on and 50% off.

>Piccolo may be considered a special case of this idea, where only one 
>carrier is sent at a time from a set of m-carriers. Phil mentioned that FHT 
>(is that for fast hadamard transform?) is used to perform demodulation. How 
>about telling us a bit more about how to implement this one Phil.

As I understand it, piccolo only sends one tone at a time. What I've
proposed is the same thing except for an additional layer of
orthogonal signalling in the form of the walsh functions on top of the
orthogonal tone set. This is the layer you'd decode with the FHT.

Whether or not this extra layer helps in a real HF channel is unknown.

Phil


From karn@qualcomm.com Wed Jan 04 22:55:55 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPkEs-0001I1C; Wed, 4 Jan 95 22:55 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA11138; Wed, 4 Jan 1995 20:57:48 -0800
Date: Wed, 4 Jan 1995 20:57:48 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501050457.UAA11138@servo.qualcomm.com>
To: k5yfw@sacdm10.kelly.af.mil
CC: hfsig@tapr.org
In-reply-to: <m0rKrSm-0002ANC@sacdm10.kelly.af.mil> (k5yfw@sacdm10.kelly.af.mil)
Subject: Re: [HFSIG:165] Re: HF Modulation Modes

>        Do we want to design a modem for the worse-case scenario or
>        can we live with one that can get data thru on the worst
>        channel part of the time.  I have a pick-up without 4 wheel
>        drive...there are at times places I can't drive...so I don't
>        drive there until conditions are better.  There are places
>        where I can drive without 4 wheel drive that my Geo Metro can
>        never go.  Should I have 4 wheel drive?  Do we need a modem
>        that can get thru even the worst conditions or can we settle
>        for something less.  Are we purist or realists?

The newer telephone modems are highly adaptive to line quality. Perhaps
*too* adaptive. Lots of different baud rates, symbol constellations
and coding rates. It helps, but it sure does complicate things if you're
not careful.

Phil
From karn@unix.ka9q.ampr.org Thu Jan 05 04:47:02 1995
Return-Path: <karn@unix.ka9q.ampr.org>
Received: from unix.ka9q.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rPpic-00004zC; Thu, 5 Jan 95 04:46 CST
Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAA08743; Thu, 5 Jan 1995 02:49:40 -0800
Date: Thu, 5 Jan 1995 02:49:40 -0800
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199501051049.CAA08743@unix.ka9q.ampr.org>
To: jmorriso@bogomips.ee.ubc.c
CC: hfsig@tapr.org
In-reply-to: <m0rLExU-0004giC@bogomips.ee.ubc.ca> (jmorriso@bogomips.ee.ubc.ca)
Subject: Re: [HFSIG:169] Re: HF Modulation Modes

>This isn't related to HF, but: would some modulation like Piccolo (I
>think I missed the description for that) be applicable to sending a
>data stream over a 2m or 70cm narrow-band FM voice radio? And
>preferably through a voice repeater as well. Speed would be  about 50
>bps or so, just enough to send your callsign or a very short message
>when you key up the radio.

Not really. The key to your question is the phrase "narrow-band". Piccolo,
and other m-ary orthogonal schemes, are specifically designed to spend
bandwidth in order to save on required S/N ratio.

Automatic transmitter IDing is already quite easily done with conventional
binary modems. I think MSK is fairly popular for this purpose on public
service radios. At least you hear it all the time on cop shows.

Phil
From esilbaug@afit.af.mil Sat Jan 07 12:10:27 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rQfap-0000QdC; Sat, 7 Jan 95 12:10 CST
Received: from eagle.afit.af.mil by stealth.afit.af.mil with SMTP id AA08932
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Sat, 7 Jan 1995 13:10:19 -0500
Date: Sat, 7 Jan 1995 13:10:19 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501071810.AA08932@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: Re: HF modulation
Cc: esilbaug@afit.af.mil


I have been following the discussion on OFDM and studying
Phil's intriguing proposal for using M-ary orthogonal FSK
with Walsh functions.  Over Christmas break (I'm pursuing
an MSEE; if only I could catch it) I did some crude
simulations of Phil's scheme using MATLAB.

First, I generated a 64x64 Hadamard matrix (whose rows are
Walsh functions).  Then I generated 64 equal amplitude
sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz.
I then picked a row at random from the Hadamard matrix to
determine which sinusoids to sum together.  I sampled the
time sequence at 32 kHz and plotted it over a full period
of the combined signal.

I used several different Walsh functions to get a feel for
the general behavior of these signals.  Since I started with
64 tones, and only 1/2 are on for any particular Walsh
function, I was combining 32 separate tones.  The results
were rather interesting, and very similar to Johan's.

Thus wrote Johan, KC7WW:

> As a way to learn more about how OFDM works for the
> 39-tone MIL-STD-188 parallel modem, I wrote a C program
> that simulates 39 parallel tones and combines them into
> a single output signal.

[snip]

> I also did capture the simulated output waveform and was
> quite concerned after inspecting the plot  -  the
> presence of large spikes of significant magnitude (in
> some cases, some 10-15 dB over the RMS value).

My simulation produced signals with peak-to-RMS ratios of
9 dB, they were generally of low amplitude except where
the sinusoids came into phase and produced a large peak,
and they generally looked 'noiselike'.  I also noticed that
the signal's peak amplitude was not symetric about the time
axis.  The signals had zero average value but the largest
positive-going peak was twice as high as the largest
negative-going peak.

As several others have noted, this high peak-to-RMS ratio
will limit the amount of energy per symbol.  A signal such
as this is potential trouble in any amplifier unless care is
taken to control the peak level.  The asymetry in peak
heights may furthur limit the amount of power an amplifier
could deliver.  This is definitely not a constant envelope
signal so linear amplifiers are in order.  As more tones are
added the signals will have larger peak-to-RMS ratios.  This
is consistent with Johan's observations since he was summing
more tones.

The FCC limits amateurs based on PEAK envelope power (PEP),
not RMS power.  As Phil noted, coding gains can buy back
most of the loss in energy per symbol caused by the low RMS
value of the signal, but it's still a significant limitation.
Disregarding interference, it's ultimately the energy per
bit that determines the performance of a digital system.

Phil's proposal was for a noncoherent system, which got me
thinking (scary, eh?).  A noncoherent system ignores the
phase of a signal; so, we have a free parameter to play with.
My initial simulation started each sinusoid at zero phase.
If we could use the phase to reduce the peak value of the
signal we could get more energy per symbol and get the coding
gain as well.

First I tried a linear shift in the initial phase across all
64 sinusoids.  I started with zero initial phase at the lowest
frequency and increased the phase linearly to two pi at the
highest frequency.  This resulted in signals with about the
same peak-to-RMS ratios (8.25 dB), still 'noiselike', but the
amplitude peaks became symetrical about the time axis
(interesting and unexpected).

My next attempt was to assign a random initial phase to
each of the 64 sinusoids. The initial phase was distributed
uniformly between zero and two pi.  This produced signals with
an average peak-to-RMS ratio of 4.75 dB, the signals looked
extremely 'noiselike', and the amplitude peaks were nearly
symetrical.  Progress!

These were just the first ways I thought of to change the
phase, there was no method to my maddness.  Even a naive
method like ramdomizing the phase produced a 4 dB reduction
in the peak-to-RMS ratio.  These results lead to a conjecture
and several questions.

My conjecture is that we can reduce the peak-to-RMS ratio
further, and maybe even approximate a constant envelope
signal, by properly choosing the phases of the sinusoids.
I think this is plausible since a wideband FM signal is a
constant envelope signal and its spectrum looks like a set
of nearly equal amplitude sinusoids, within a limited
bandwidth.  I doubt we could get a truly constant envelope
signal because we are using a small set of harmonically
related sinusoids.

Some questions I have:

   -  Are there systematic methods for choosing the
      initial phases of the sinusoids to minimize the
      peak-to-RMS ratio?

   -  What limits are there on reducing the peak-to-RMS
      ratio?

   -  Are these limits, if they exist, related to the
      number of sinusoids or the Walsh function used?

   -  Is this a well-known (or obscure) problem that
      already has a solution?

   -  Is reducing the peak-to-RMS ratio really as
      important as I seem to think it is?

The MIL-STD modems apparently use PSK on the tones as well.
Since the phase of any particular sinusoid in my simulation
was constant over the symbol period this should allow using
methods such as DPSK on the tones if someone wants to add an
additional layer of modulation.  Would this increase the
peak-to-RMS ratio?

I can provide the MATLAB M-files I used for this simulation
if anyone is interested in duplicating, or extending, my
results.  Thoughts anyone?

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply

From larry@owrlakh.unbc.edu Sat Jan 07 16:05:10 1995
Return-Path: <larry@owrlakh.unbc.edu>
Received: from owrlakh.unbc.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rQjFw-0000hUC; Sat, 7 Jan 95 16:05 CST
Received: (from larry@localhost) by owrlakh.unbc.edu (8.6.9/8.6.9) id OAA02948 for hfsig@tapr.org; Sat, 7 Jan 1995 14:04:57 -0800
From: Larry Gadallah <larry@owrlakh.unbc.edu>
Message-Id: <199501072204.OAA02948@owrlakh.unbc.edu>
Subject: Re: [HFSIG:183]
To: hfsig@tapr.org
Date: Sat, 7 Jan 1995 14:04:56 -0800 (PST)
In-Reply-To: <m0rQfgn-0000Coa@dptspd.sat.datapoint.com> from "hfsig@tapr.org" at Jan 7, 95 12:16:00 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1175      

Eric E Silbaugh <esilbaug@afit.af.mil> writes:
> 
> I have been following the discussion on OFDM and studying
> Phil's intriguing proposal for using M-ary orthogonal FSK
> with Walsh functions.  Over Christmas break (I'm pursuing
> an MSEE; if only I could catch it) I did some crude
> simulations of Phil's scheme using MATLAB.
> 
> First, I generated a 64x64 Hadamard matrix (whose rows are
> Walsh functions).  Then I generated 64 equal amplitude
> sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz.
> I then picked a row at random from the Hadamard matrix to
> determine which sinusoids to sum together.  I sampled the
> time sequence at 32 kHz and plotted it over a full period
> of the combined signal.
>
Can anyone provide a good reference to what some of these 
things are (i.e. Walsh functions, Hadamard matrices)?

Thanks and 73,
-- 
---------------------------------------------------------------------
Larry Gadallah                       Prince George, BC
Internet: larry@owrlakh.unbc.edu     TPC: (604) 964-1140
VE4TCP/VE6VQ                         ICBM: 53:51'38.4"N 122:44'25.8"W
---------------------------------------------------------------------
From k5yfw@sacdm10.kelly.af.mil  Mon Jan 09 08:31:36 1995
Return-Path: <k5yfw@sacdm10.kelly.af.mil>
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRL8A-0000bPC; Mon, 9 Jan 95 08:31 CST
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0rRL3U-0002CeC; Mon, 9 Jan 95 08:26 CST
Message-Id: <m0rRL3U-0002CeC@sacdm10.kelly.af.mil>
Date: Mon, 9 Jan 95 08:26:43 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: G-TOR Goes Public
To: hfsig@tapr.org
Reply-to: k5yfw@sat.ampr.org





                          G-TOR Goes Public

                        by Walt DuBose, K5YFW

While at the local "ham store" on Christmas Eve, my XYL WB5WXY,
suggested that I buy a "ham book" (she meant magazine I'm sure) to
read while we were flying to Idaho Christmas day.

While looking at the various "books", I spotted "G-TOR, The New Mode".
My wife was a little surprised at the $16 price but I assured here
this would keep me occupied and it has.

The cover says "Articles, Charts, Protocol".  Copyright by Kantronics,
this 90 page book is crammed with articles and papers on G-TOR.  While
many articles are redundant, reading several articles will give you a
good working knowledge of G-TOR and why Kantronics is proud of their
product.

Not only is the book filled with articles, it also contains charts
and a complete description of the protocol.

I will have to re-read several articles to ensure that I fully
understand this protocol.  For those with programming background, I
feel confident that they will get much more out of this book that a
non-technical person like me.

While not everyone will want to rush out and purchase this book,
those truly interested in high speed HF data communications will
want a copy.  This is also an excellent reference for your radio
club's library.
From k5yfw@sacdm10.kelly.af.mil  Mon Jan 09 10:25:26 1995
Return-Path: <k5yfw@sacdm10.kelly.af.mil>
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRMuH-0000f2C; Mon, 9 Jan 95 10:25 CST
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0rRMpu-0001zfC; Mon, 9 Jan 95 10:20 CST
Message-Id: <m0rRMpu-0001zfC@sacdm10.kelly.af.mil>
Date: Mon, 9 Jan 95 10:20:49 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: G-TOR Booklet
To: rs@ife.ee.ethz.ch
Cc: hfsig@tapr.org
X-orig-date: Mon, 9 Jan 95 16:13:55 MET
X-orig-from: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
X-orig-message-ID: <9501091513.AA05551@ife>

I'm sorry, I guess I should have included the information.  The title
of the book is "G-TOR, The New Mode", copyright and published by:

        Kantronics Company, Inc
        1202 E. 23rd St.
        Lawrence, KS 66046

        U.S. Telephone Number: 913/842-7745

I believe you can only get it from Kantronics or through one of their
equipment distributors.

73,

Walt


In your message of  9 Jan 1995 at 1613 CST, you write:
> Hi Walt
>
> Thanks for your very interesting hint.
> Could you please give us (overseas) more info about publisher/publishing date and place
> and so on, so that we can order it by a local book-store.
> Maybe this booklet even has an international book number (in the form of ISSN-...) or
> maybe there is an indication/address/fax-number where we could purchase it ?
>
> (I am probably not going to implement that protocol on my DSP (as I did with PACTOR), but
> would also enjoy the reading about the algorithms behind).
>
> Thanks for your help es vy 73s,
> Rolf
> --
>                                 --- * * * ---
>
> Rolf Sommerhalder
> Swiss Federal Institute of Technology (ETH)   home address:
> Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
> Gloriastrasse 35                              Wermatswilerstrasse 96
> 8092 Zurich / Switzerland                     8610 Uster / Switzerland
> 
> Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
> Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
> E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81
> 
From shall@rain.org Mon Jan 09 11:03:05 1995
Return-Path: <shall@rain.org>
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRNUm-0000T9C; Mon, 9 Jan 95 11:03 CST
Received: by coyote.rain.org(4.1/SMI-RAIN) with id AA01767 
	  for hfsig@tapr.org on Mon, 9 Jan 95 08:59:12 PST
Date: Mon, 9 Jan 1995 08:59:11 -0800 (PST)
From: Stephen Hall <shall@rain.org>
To: hfsig@tapr.org
Cc: Ross duClair <CPTRoss@aol.com>
Subject: Re: [HFSIG:186] Re: G-TOR Booklet
In-Reply-To: <m0rRMpu-0001zfC@sacdm10.kelly.af.mil>
Message-Id: <Pine.SUN.3.90.950109085422.1092A-100000@coyote.rain.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Rolf, Regarding G-TOR: I attended a talk given by Phil Anderson regarding
G-TOR vs. Pactor and it appeared that G-TOR has much more powerful error
correction than Pactor.  I would be interested in your evaluation after
you have had an opportunity to check it out. Steve, WM6P



On Mon, 9 Jan 1995, WALT DUBOSE - K5YFW wrote:

> I'm sorry, I guess I should have included the information.  The title
> of the book is "G-TOR, The New Mode", copyright and published by:
> 
>         Kantronics Company, Inc
>         1202 E. 23rd St.
>         Lawrence, KS 66046
> 
>         U.S. Telephone Number: 913/842-7745
> 
> I believe you can only get it from Kantronics or through one of their
> equipment distributors.
> 
> 73,
> 
> Walt
> 
> 
> In your message of  9 Jan 1995 at 1613 CST, you write:
> > Hi Walt
> >
> > Thanks for your very interesting hint.
> > Could you please give us (overseas) more info about publisher/publishing date and place
> > and so on, so that we can order it by a local book-store.
> > Maybe this booklet even has an international book number (in the form of ISSN-...) or
> > maybe there is an indication/address/fax-number where we could purchase it ?
> >
> > (I am probably not going to implement that protocol on my DSP (as I did with PACTOR), but
> > would also enjoy the reading about the algorithms behind).
> >
> > Thanks for your help es vy 73s,
> > Rolf
> > --
> >                                 --- * * * ---
> >
> > Rolf Sommerhalder
> > Swiss Federal Institute of Technology (ETH)   home address:
> > Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
> > Gloriastrasse 35                              Wermatswilerstrasse 96
> > 8092 Zurich / Switzerland                     8610 Uster / Switzerland
> > 
> > Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
> > Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
> > E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81
> > 
> 
From BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com Mon Jan 09 13:27:35 1995
Return-Path: <BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com>
Received: from hp.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRPka-00013TC; Mon, 9 Jan 95 13:27 CST
Received: from opnmail3.corp.hp.com by hp.com with SMTP
	(1.37.109.14/15.5+ECS 3.3) id AA074039647; Mon, 9 Jan 1995 11:27:27 -0800
Received: from  by opnmail3.corp.hp.com with SMTP
	(1.37.109.8/15.5+ECS 3.3) id AA25081; Mon, 9 Jan 1995 11:27:26 -0800
From: BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com
X-Openmail-Hops: 2
Date: Mon, 9 Jan 95 11:11:00 -0800
Message-Id: <d0ey1Sy000000000@MHS>
Subject: Re: HF modulation
To: hfsig@tapr.org


Eric Silbaugh wrote:

(Re: OFDM)

>My simulation produced signals with peak-to-RMS ratios of
>9 dB,  ...

>As several others have noted, this high peak-to-RMS ratio
>will limit the amount of energy per symbol.   ...

>The FCC limits amateurs based on PEAK envelope power (PEP),
>not RMS power.  As Phil noted, coding gains can buy back
>most of the loss in energy per symbol caused by the low RMS
>value of the signal, but it's still a significant limitation.
>Disregarding interference, it's ultimately the energy per
>bit that determines the performance of a digital system. ...

Of course, lower average power also means less interference to
other users.  Since the signal will be spread over several kHz,
the energy per 300 Hz channel will be low.  Interference *from*
other users (analog or digital) can be reduced with proper coding.

>A noncoherent system ignores the
>phase of a signal; so, we have a free parameter to play with.
>My initial simulation started each sinusoid at zero phase.
>If we could use the phase to reduce the peak value of the
>signal we could get more energy per symbol and get the coding
>gain as well. ...

>My next attempt was to assign a random initial phase to
>each of the 64 sinusoids. The initial phase was distributed
>uniformly between zero and two pi.  This produced signals with
>an average peak-to-RMS ratio of 4.75 dB, the signals looked
>extremely 'noiselike', and the amplitude peaks were nearly
>symetrical.  Progress!

>These were just the first ways I thought of to change the
>phase, there was no method to my maddness.  Even a naive
>method like ramdomizing the phase produced a 4 dB reduction
>in the peak-to-RMS ratio. ...

The "naive method" may be pretty close to optimal.  Since the
number of cycles per symbol of each carrier differs from each
of the others by an integer number of cycles, each pair of
carriers will be in phase (3 dB peak-to-average) sometime
during each symbol.  Intuitively, it seems like you could
never do that well with many carriers.

Al Bloom N1AL
From FORRERJ@frl.orst.edu Mon Jan 09 13:59:56 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRQFq-0000zFC; Mon, 9 Jan 95 13:59 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id EAA24359 for <hfsig@tapr.org>; Mon, 9 Jan 1995 04:37:54 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 9 Jan 95 11:57:57 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 9 Jan 95 11:57:54 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 9 Jan 1995 11:57:49 PST8PDT
Subject:       Re: [HFSIG:188] Re: HF modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <D33ED2758A7@frl.orst.edu>

Eric E. Silbaugh wrote:

>I have been following the discussion on OFDM and studying
>Phil's intriguing proposal for using M-ary orthogonal FSK
>ith Walsh functions.  Over Christmas break (I'm pursuing
>an MSEE; if only I could catch it) I did some crude
>simulations of Phil's scheme using MATLAB.

>First, I generated a 64x64 Hadamard matrix (whose rows are
>Walsh functions).  Then I generated 64 equal amplitude
>sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz.
>I then picked a row at random from the Hadamard matrix to
>determine which sinusoids to sum together.  I sampled the
>time sequence at 32 kHz and plotted it over a full period
>of the combined signal.

 .....snip.....

>   -  Are there systematic methods for choosing the
>      initial phases of the sinusoids to minimize the
>      peak-to-RMS ratio?

Eric, just a suggestion: you may want to look at an earlier (way back) 
message thread on this very topic. It is recorded in an archive on ftp.ucsd 
in the DSP directory. If you have a problem obtaining it, I'll dig out the
name of the archive. 

I think there is no good news here. There is no easy solution as far as 
I can gather (?). CLOVER, as an example, addressed this problem by using
time and frequency interleaved signaling as well as pulse shaping.


...... more snipping .....

 
>The MIL-STD modems apparently use PSK on the tones as well.
>Since the phase of any particular sinusoid in my simulation
>was constant over the symbol period this should allow using
>methods such as DPSK on the tones if someone wants to add an
>additional layer of modulation.  Would this increase the
>peak-to-RMS ratio?


I suspect it depends on the peak of the individual channel waveform. 


>I can provide the MATLAB M-files I used for this simulation
>if anyone is interested in duplicating, or extending, my
>results.  Thoughts anyone?

I, for one, am quite interested in your work, Eric. Likewise, if
anyone is interested in the OFDM simulation, I would be happy to share
the "C" source code.


A bit of progress over the last weekend: I finished a FFT-based display 
scope program for the DSP sound card. Since I am interested in using the
FFT-approach for doing an OFDM modem, thought that I could use the same
FFT for different purposes. It's a 256-point radix-4 that includes
a Hanning window (and log transform for calculations in dB, if needed) and
does it in approximately 250 micro seconds. The first thing I did was to 
look at the audio frequency responses of my ICOM 751 - boy! was I 
surprised. 

I went ahead and played with the DSP sound card and implemented the parallel
tone modulator and FFT-based OFDM demodulator - it is surprising to see 
how sensitive the FFT is to any clipping effects of these large spikes in 
the signal. One has to be real careful of this, else a bit of garbage seem 
to appear in the wrong frequency bins. However, when this kind of garbage 
ends up in the wrong frequency bin, it seems to appear as uncorrelated 
noise - the actual signal in the frequency bin still appears quite distinct
and recoverable. Perhaps this side-effect is not all that serious
after all. Comments?

73's

Johan, KC7WW
From jojo@asti.dost.gov.ph Tue Jan 10 05:01:14 1995
Return-Path: <jojo@asti.dost.gov.ph>
Received: from christine.asti.dost.gov.ph by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRdkv-0000MrC; Tue, 10 Jan 95 04:24 CST
Received: from pia.dost.gov.ph (pia.asti.dost.gov.ph [165.220.44.53]) by christine.asti.dost.gov.ph (8.6.9/8.6.9) with SMTP id RAA04238; Tue, 10 Jan 1995 17:59:20 +0800
Date: Tue, 10 Jan 1995 17:59:20 +0800
From: "Victorio O. Ochave" <jojo@asti.dost.gov.ph>
Message-Id: <199501100959.RAA04238@christine.asti.dost.gov.ph>
To: hfsig@tapr.org
Subject: HF DSPs
Cc: jojo@christine.asti.dost.gov.ph

I'm a new member of the list, and also new in data comm over HF. We will be establishing some HF links here in the Philippines using GTOR. I was told that there are DSP filter units (Timewave DSP 59+) useful for PACTOR and AMTOR links. I was wondering if the same DSP units can make a substantial improvement in performance when using the GTOR protocol.

All commentaries and advise on this will be highly appreciated.



---------------------------------------------------------------
Victorio A. Ochave, Jr.
Communications Engineering Division
Advanced Science and Technology Institute (ASTI)
Department of Science and Technology (DOST)
4/F NEC Bldg., University of the Philippines
Diliman, Quezon City, PHILIPPINES 1101

voice: 632 995071-9 loc.5106
fax: 632 9224714
Internet: jojo@asti.dost.gov.ph
          ochave@itu.ch 
          v.ochave@ieee.org
X.400: G=victorio; S=ochave; P=itu; A=arcom; C=ch 

---------------------------------------------------------------

From Rick_Whiting@ATK.COM Tue Jan 10 10:35:51 1995
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRjXq-0000oJC; Tue, 10 Jan 95 10:35 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id KAA18813; Tue, 10 Jan 1995 10:34:37 -0600
Message-Id: <199501101634.KAA18813@ATK.COM>
Date: 10 Jan 1995 10:39:11 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: Re: [HFSIG-190] HF DSPs
To: hfsig@tapr.org

        Reply to:   RE>[HFSIG:190] HF DSPs
Date: 1/10/95 5:14 AM
To: Rick Whiting
From: hfsig@tapr.org
Victorio A. Ochave, Jr. <jojo@asti.dost.gov.ph> wrote:

>I'm a new member of the list, and also new in data comm over HF. We >will be
establishing some HF links here in the Philippines using GTOR. I >was told
that there are DSP filter units (Timewave DSP 59+) useful for >PACTOR and
AMTOR links. I was wondering if the same DSP units can >make a substantial
improvement in performance when using the GTOR >protocol.

>All commentaries and advise on this will be highly appreciated.

Victorio, If the AF DSP filter helps for PACTOR and AMTOR it will similarly
help for G-TOR.  However, it is highly desired to develop the selectivity as
high up in the receiver's IF as practical, rather than at AF.  If the IF
filters are too wide relative to the desired signal bandwidth, noise and
interference outside the AF passband will still impact the radio, e.g., the
AGC, and degrade reception even though you don't "hear" it out of the AF
(DSP) filter.

Unfortunately, many folks are trapped into using the too-wide filters that
are supplied with their transceivers for HF data modes like PACTOR and G-TOR.
 And since the filters were not designed for data with respect to phase
linearity, especially at the edges, the stock filters with about the "right"
bandwidth may not work well either!  Thus, in many practical applications the
DSP filter at AF significantly improves performance.

By the way, I think the Timewave DSP filters are top notch.

73/Rick W0TN
--------------------------------------





From karn@qualcomm.com Tue Jan 10 19:57:45 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rRsJY-0001UlC; Tue, 10 Jan 95 19:57 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA25908; Tue, 10 Jan 1995 17:59:18 -0800
Date: Tue, 10 Jan 1995 17:59:18 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501110159.RAA25908@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <CA0CBB055C2@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:173] HF Modulation

Johan says:

>Bob asked an interesting question: whether soft decision decoding 
>with convolutional coding was as effective as linear block coding 
>with interleaving.

I'd been meaning to comment on this, glad you reminded me.

I've learned that this has been a rather controversial subject that
some people argue with a fervor that approaches the classic VC vs
datagram wars of 10 years ago.

Up front I should say that I happen to work for one of the main
parties to this debate (Andrew Viterbi) so my comments may be biased.

Convolutional coding has the following general advantages:

1. Better performance for equivalent code complexity

2. Can use "soft decision" information for improved performance
(2dB on AWGN) much more easily

3. More easily adapted to arbitrary block sizes

Block codes, as typified by Reed Solomon codes, have the following
general advantages:

1. No performance penalty for "systematic" codes (where the data
appears unchanged as a subset of the coded output)

2. Complex codes more easily implemented (partially negating
convolutional advantage #1)

3. No need to "tail off" blocks for full coding gain

4. Less sensitive to burst errors

5. Direct adaptability to higher-order modulation symbol alphabets,
such as the m-ary FSK schemes I've been discussing.

Nobody really disputes the correctness of any of these points, since
they're amenable to mathematical proof. The arguments all center over
the relevance of their assumptions, and which advantages are more
important in practice.  For example, both Viterbi and Reed-Solomon
decoders are amenable to VLSI implementation, but differences in the
details can give one a temporary advantage over the other.

It's also common to combine convolutional and block codes to get the
best of both worlds. These "concatenated" coding systems are commonly
used in deep space communications, starting with Voyager. You run
a Reed-Solomon block code on top of a Viterbi-decoded convolutional
code, usually with an interleaver between the two.

The Viterbi decoder does most of the work, and since it's directly
connected to the modem it can benefit from soft decision samples. But
when the Viterbi decoder is temporarily overwhelmed, it emits bursts
of "hard" (binary) errors that are well adapted to the capabilities of
the Reed Solomon decoder.

The Voyager concatenated coding system is fairly simple by modern
standards and is well within our capability. I've already done the
Viterbi decoder for the NASA standard r=1/2 K=7 convolutional code.
N9FZX has done a Reed-Solomon decoder that may be the same one that
Voyager uses, but I'm not sure. In any event, all you need to combine
the two is some glue (interleaving, buffering, etc). The waterfall
curve for the Voyager coding scheme is a nearly vertical wall at
around 2-2.5dB.

Galileo uses the same basic techniques, but taken to some wild
extremes to squeeze the most out of the omnidirectional antenna since
the failure of the main antenna. The convolutional code has r=1/4,
K=14, which is extremely high for a Viterbi decoder (the work factor
increases exponentially with K). And the RS code uses varying amounts
of redundancy per block which permits a trick called "redecoding".

First you run the Viterbi decoder. Then you run the RS decoder on the
output.  Some of the RS blocks will decode, some won't; the blocks
with more redundancy being more likely to decode. You fill in the
missing symbols in the decoded blocks and then toss them back to the
Viterbi decoder for another go with the RS-decoded states "pinned
down". Then you have a second go at the RS decoder. You iterate this
perhaps 4-5 times until things stop improving. The end result is an
astonishingly low Eb/N0 requirement of about 0.56dB, damn near the
Shannon limit for that channel. Of course, they do this at only 10 b/s
on a Sparcstation...

Phil

From FORRERJ@frl.orst.edu Wed Jan 11 10:51:48 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rS6Gv-0000yNC; Wed, 11 Jan 95 10:51 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA04424 for <hfsig@tapr.org>; Wed, 11 Jan 1995 01:30:11 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 11 Jan 95 8:50:18 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 8:50:14 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 11 Jan 1995 08:50:14 PST8PDT
Subject:       Re: [HFSIG:192] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <D60CDC50F6D@frl.orst.edu>

Hi Phil,

That essay on coding was welcomed by everyone - well done! 

I would just like to add, if I may, one further thought relating 
specifically to the multitone signaling systems and coding methods. In a 
previous posting I mentioned the work by Pierce et, al. - nobody seems to 
have commented on that. Before it is lost - here is a brief summary:

The fact that was established in this research paper, that was based on 
actual transatlantic and transcontinental HF data links at various HF 
frequencies, was that HF disturbances has somewhat characteristic 
nature, either broadband and/or noise bursts in conjunction with various 
forms of fading. This often has some frequency/sequency effects that could 
be put to good use in the type of coding applied, i.e. the choice of 
interleaving/constraint length for example.

The second fact that the research established, was that channel spacing, 
(i.e. signaling over othoganally spaced channels) appears to have a 
systematic effect on BER. For example, if you look at BER vs. coding 
scheme, cyclic behavior with distinct minima is observed - that tells us 
that it is possible to optimise coding gain by proper choice of 
parameters, such as constraint length, interleave factor, and type of code.

Taking these observations into account, as I have indicated in my earlier 
posting - an appropiate convolutional coder or the right type of block 
code was equally effective on parallel tone modems. This reseach was done 
prior to soft-decision coding becoming popular and I am sure other advances 
were made in coding theory since. 
  
There is no question that a combined block/convolutional code, possibly 
with soft-decision coding, will buy us the best of both worlds. Coding 
theory, however, is not one of the easiest of fields to wrestle with - for 
one, it does not allow the same degree of intuition or gut feeling to be 
applied as for instance modulation/demodulation theories. You really have 
to know what you are doing.

I think we all agree that we are very much dependant on the guidance and 
contribuitions of experts like Phil. 

Looking forward to learning more about this field.

73's

Johan, KC7WW








From jmorriso@bogomips.ee.ubc.ca  Wed Jan 11 13:33:41 1995
Return-Path: <bogomips.ee.ubc.ca!jmorriso@rflab.ee.ubc.ca>
Received: from rflab.ee.ubc.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rS8nR-0001PbC; Wed, 11 Jan 95 13:33 CST
Received: from bogomips.ee.ubc.ca by rflab.ee.ubc.ca  with uucp
	(Linux Smail3.1.28.1 #1) id m0rS8lP-0000SFC; Wed, 11 Jan 95 11:31 PST
Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 #3)
	id m0rS8KB-0004gbC; Wed, 11 Jan 95 11:03 PST
Message-Id: <m0rS8KB-0004gbC@bogomips.ee.ubc.ca>
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
Subject: voice?
To: hfsig@tapr.org
Date: Wed, 11 Jan 1995 11:03:15 -0800 (PST)
X-Linux: watch for Linux '95 aka "Helsinki"
X-Bogomips: 33.55
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 836       


Will these 2400bps HF modems be able to work with digitized+compressed
voice?  (CELP or something). That would really be something to impress
the regular (digital is for weenies) HFers! The answer should be 'yes'
if the BER is reasonable and it would be 'usable' if there's no long
training sequence between modems (I mean you couldn't key up and say
'QSL' or something short if it took 10 seconds to train every time).

I don't know what's available in hardware voice compression etc., but
the ICs are no doubt getting cheap.



---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------

From shall@rain.org  Wed Jan 11 14:41:55 1995
Return-Path: <shall@rain.org>
Received: from coyote.rain.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rS9rc-0001RxC; Wed, 11 Jan 95 14:41 CST
Received: from  by coyote.rain.org(4.1/SMI-RAIN) with id AB19335 
	  for hfsig@tapr.org on Wed, 11 Jan 95 12:36:59 PST
Date: Wed, 11 Jan 95 12:36:59 PST
Message-Id: <9501112036.AB19335@coyote.rain.org>
X-Sender: shall@rain.org
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: shall@rain.org (Steve Hall)
Subject: Re: [HFSIG:190] HF DSPs

Victorio,

If you would care to run any on the air tests on G-TOR to Southern California
please let me know.

Steve Hall, WM6P

>I'm a new member of the list, and also new in data comm over HF. We will be
establishing some HF links here in the Philippines using GTOR. I was told
that there are DSP filter units (Timewave DSP 59+) useful for PACTOR and
AMTOR links. I was wondering if the same DSP units can make a substantial
improvement in performance when using the GTOR protocol.
>
>All commentaries and advise on this will be highly appreciated.
>
>
>
>---------------------------------------------------------------
>Victorio A. Ochave, Jr.
>Communications Engineering Division
>Advanced Science and Technology Institute (ASTI)
>Department of Science and Technology (DOST)
>4/F NEC Bldg., University of the Philippines
>Diliman, Quezon City, PHILIPPINES 1101
>
>voice: 632 995071-9 loc.5106
>fax: 632 9224714
>Internet: jojo@asti.dost.gov.ph
>          ochave@itu.ch 
>          v.ochave@ieee.org
>X.400: G=victorio; S=ochave; P=itu; A=arcom; C=ch 
>
>---------------------------------------------------------------
>
>
>
Steve Hall

From FORRERJ@frl.orst.edu Wed Jan 11 14:43:13 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rS9oF-0001VPC; Wed, 11 Jan 95 14:38 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id FAA06132 for <HFSIG@tapr.org>; Wed, 11 Jan 1995 05:06:19 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 11 Jan 95 12:26:26 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 12:26:12 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Wed, 11 Jan 1995 12:26:08 PST8PDT
Subject:       Software tools for soundcard
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <D6467482522@frl.orst.edu>

Hi all,

For those folks working or planning to work with the PSA sound cards, here 
is some great news.

According to a post on Usenet, version 5.01 of the Analog Devices' software 
development tools for the 21xx DSP is available via anonymous ftp. This 
toolkit is professional quality and include, amongst other things, the GNU C 
compiler, GNU assembler, linker, prom splitter, and simulator. Since I have 
purchased this software some time ago (without knowing that it was on the 
net), and used it extensively, I can highly recommend it. 

Only minor changes are necessary to the software that I have previously 
made available. In fact, the host code requires only commenting out one line 
of code. The DSP code requires a few changes - though nothing serious. The 
fact that you can now concentrate on your DSP application instead of 
concering yourself with how and where stuff gets loaded and cross-linked, 
makes programming the DSP a pleasure. 

The software tools are available at: ftp.analog.com in 
directory /pub/dsp/devtools/21xx. It's some 2.8 M, so beware. I downloaded 
it yesterday (1/10/95) to make sure it was'nt a hoax - its real OK, but I'm 
not sure whether this is an accident? 

Trust this is of interest.

73's

Johan, KC7WW



From k5yfw@sacdm10.kelly.af.mil  Wed Jan 11 14:54:42 1995
Return-Path: <k5yfw@sacdm10.kelly.af.mil>
Received: from sacdm10.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSA3y-0001XIC; Wed, 11 Jan 95 14:54 CST
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0rS9zi-0002BuC; Wed, 11 Jan 95 14:50 CST
Message-Id: <m0rS9zi-0002BuC@sacdm10.kelly.af.mil>
Date: Wed, 11 Jan 95 14:50:14 -0600
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:194] voice?
To: hfsig@tapr.org
X-orig-date: Wed, 11 Jan 95 13:42 CST
X-orig-from: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
X-orig-message-ID: <m0rS8KB-0004gbC@bogomips.ee.ubc.ca>

The MIL-STD-188-110A (39 parallel tone) modems were designed to do
just that.  In fact, the first 39 parallel tone modem I ever saw (in
about 86 or 87) was in a voice encryption device.  I believe the
military used LCP10 voice encryption.   -- k5yfw


In your message of 11 Jan 1995 at 1342 CST, you write:
>
> Will these 2400bps HF modems be able to work with digitized+compressed
> voice?  (CELP or something). That would really be something to impress
> the regular (digital is for weenies) HFers! The answer should be 'yes'
> if the BER is reasonable and it would be 'usable' if there's no long
> training sequence between modems (I mean you couldn't key up and say
> 'QSL' or something short if it took 10 seconds to train every time).
>
> I don't know what's available in hardware voice compression etc., but
> the ICs are no doubt getting cheap.
>
>
>
> ---------------------------------------------------------------------------
> BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
> jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org
> ---------------------------------------------------------------------------
>
From esilbaug@afit.af.mil Wed Jan 11 16:11:15 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp

	(Smail3.1.29.1 #5) id m0rSBG4-0001L5C; Wed, 11 Jan 95 16:11 CST
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA24672
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 11 Jan 1995 17:11:09 -0500
Date: Wed, 11 Jan 1995 17:11:09 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501112211.AA24672@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: Peak Reduction (was RE: HF Modulation)
Cc: esilbaug@afit.af.mil


Al,

I agree, "...lower average power means less interference to other users. ..."
I would just add the phrase ",except during the peaks".  Think about it this
way.  Take the total energy in a "peaky" signal and spread it evenly across
the entire symbol period.  This is analogous to Phil's scheme of spreading
the energy evenly over frequency, just in the time domain.  This would give
a signal with the same energy and even less interference.

Speaking of my "naive" phase randomization method, you wrote:

> The "naive method" may be pretty close to optimal.  .....

I hope not, but I don't know a better way (yet).  As you point out, a single
sinusoid has a 1.5 dB peak-to-RMS ratio and is probably the lower limit.
Randomizing the initial phases in my simulation gave an average 5 dB peak-to-
RMS ratio.  There is room for improvement.  How much improvement we can obtain,
and how to do it practically, are open questions.

This may just be my SATCOM background coming back to haunt me.  Satellite
transponders can be very nonlinear.  Constant envelope modulation methods
are widely used because they are distorted less and produce less interference
to other users on the same transponder.

The whole question of whether reducing the peak-to-RMS ratio provides real
benefits is another open question.  Probably the best way to find out is to
start testing these methods over the air and on Johan's channel simulator.
Radio amateurs, start your modems!

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From esilbaug@afit.af.mil Wed Jan 11 16:12:24 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSBHA-0001VPC; Wed, 11 Jan 95 16:12 CST
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA24707
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 11 Jan 1995 17:12:13 -0500
Date: Wed, 11 Jan 1995 17:12:13 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501112212.AA24707@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: Peak Reduction (was RE: HF Modulation)
Cc: esilbaug@afit.af.mil


Johan,

Just curious, what surprised you about your radio's audio response?

About your FFT and clipping.  Think about each frequency bin as a channel in
a satellite transponder, and each tone as a channel being used.  Now send
this through a nonlinear transponder that limits the composite signal.  Those
intermodulation products cause serious problems.  You just saw what a SATCOM
engineer faces trying to make a DAMA (demand assigned, multiple access)
network useable.  Whether IMD will affect HF modems remains to be seen.  I
suspect it will, negatively.

I think M-ary orthogonal FSK or OFDM (whatever you want to call it) has
potential as a simple and robust modulation method for DSP-based HF modems.
The FFT seems to be a natural algorithm for this.  We also have the working
examples of Clover and the MIL-STD modems to guage our performance against.

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From FORRERJ@frl.orst.edu Wed Jan 11 17:51:26 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSCp0-0001ZAC; Wed, 11 Jan 95 17:51 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA07529 for <hfsig@tapr.org>; Wed, 11 Jan 1995 08:29:48 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 11 Jan 95 15:49:55 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 11 Jan 95 15:49:49 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 11 Jan 1995 15:49:41 PST8PDT
Subject:       Re: ICOM 751 Filter response curves
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <D67CC315CCE@frl.orst.edu>

Hi Eric,

What surprized me was to see the different filter responses for "RTTY" and 
"LSB". RTTY mode gave a fairly steep shirt starting around 1500 Hz, then 
tapered off, nearly in a linear fashion, down to 4kHz - no "flat top" at 
all. LSB, on the other hand, contained a band between approximaely 300 
Hz and 2600 Hz, though not a very clean filter response shape. If, for 
instance, the full 3kHz is required for a parallel modem, there would be 
some impact on the channels closer to the band edges.

What I am seeing, of course, is a result of the rig's audio output 
response at the headphone jack as well as the sound card's audio input 
response. Perhaps a better place to tap this audio would be at a 
point before the audio stages. 

The tests were mainly to play with the real-time FFT scope and is actually 
the same DSP code used in the parallel modem demodulator. Fun stuff.

Johan, KC7WW

From k5yfw@k5yfw.ampr.org  Wed Jan 11 21:36:13 1995
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSGJA-0000sJC; Wed, 11 Jan 95 21:34 CST
Date: Wed, 11 Jan 95 21:05:25 CST
Message-Id: <2471@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:200] Re: ICOM 751 Filter response curves
In-Reply-To: Your message of Wed, 11 Jan 95 17:54 CST
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

In message <D67CC315CCE@frl.orst.edu> Johan writes:
> Hi Eric,
> 
> What surprized me was to see the different filter responses for "RTTY" and 
> "LSB". RTTY mode gave a fairly steep shirt starting around 1500 Hz, then 
> tapered off, nearly in a linear fashion, down to 4kHz - no "flat top" at 
> all. LSB, on the other hand, contained a band between approximaely 300 
> Hz and 2600 Hz, though not a very clean filter response shape. If, for 
> instance, the full 3kHz is required for a parallel modem, there would be 
> some impact on the channels closer to the band edges.

        The AN/URC-119 (Harris RF-350) HF military/commercial
        transceiver has 3 KHz SSB filters...one of each sideband.  I
        have run IF bandpass checks on them and they have a very clean
        response and quite a sharp cutoff above 3 KHz...much cleaner
        than amateur equipment as noted above.  This might mean that
        some BW less than 3 KHz would be needed of compensation for the
        upper 1 KHz of the IF bandpass.

> 
> What I am seeing, of course, is a result of the rig's audio output 
> response at the headphone jack as well as the sound card's audio input 
> response. Perhaps a better place to tap this audio would be at a 
> point before the audio stages. 

        The AN/URC-119 (Harris RF-350) has an audio jack that bypasses
        the speaker audio stages and mic. amp. stages.  The audio there
        is much cleaner that at the mic. or headphone jacks.  This is
        where they connect the MIL-STD-188-110A (39 tone) modem.

        On my IC-735, I have found that the audio jacks on the back
        panel provide much cleaner audio for data work.  I don't know if
        the IC-751 has such a jack.

> 
> The tests were mainly to play with the real-time FFT scope and is actually 
> the same DSP code used in the parallel modem demodulator. Fun stuff.
>
        The MIL-STD modems require 10 Hz dial resolution read-out but the
        frequency *MUST* be within about 3 or 4 Hz to the modems to work
        correctly.  That would require some kind of "on-screen" tuning
        for use with an amateur radio...except for something like the
        SGC-2000 or Kenwood TKM-707 which are commercial radios with the
        SGC meeting MIL-Specs.

 
Walt@home.2.nite
From karn@qualcomm.com Thu Jan 12 01:21:24 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSJqT-0000XqC; Thu, 12 Jan 95 01:21 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id XAA05968; Wed, 11 Jan 1995 23:23:22 -0800
Date: Wed, 11 Jan 1995 23:23:22 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501120723.XAA05968@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: More on Galileo coding

Here's an abstract I found on a NASA web server that summarizes the
coding tricks they're using to milk the most out of the low-gain
antenna on Galileo. Of course, the deep space channel is very
different from the HF channel, but it gives you an idea of what coding
can do.

             Enhanced decoding for the Galileo S-band mission

                        DOLINAR, S.; BELONGIE, M.


      Jet Propulsion Lab., California Inst. of Tech., Pasadena, CA.


Published: August 1993           Pages:  00016       Biblio Refs: 0

    A coding system under consideration for the Galileo S-band low-gain
   antenna mission is a concatenated system using a variable redundancy
   Reed-Solomon outer code and a (14,1/4) convolutional inner code. The
   8-bit Reed-Solomon symbols are interleaved to depth 8, and the eight
   255-symbol codewords in each interleaved block have redundancies 64,
   20, 20, 20, 64, 20, 20, and 20, respectively (or equivalently, the
   codewords have 191, 235, 235, 235, 191, 235, 235, and 235 8-bit
   information symbols, respectively). This concatenated code is to be
   decoded by an enhanced decoder that utilizes a maximum likelihood
   (Viterbi) convolutional decoder; a Reed Solomon decoder capable of
   processing erasures; an algorithm for declaring erasures in undecoded
   codewords based on known erroneous symbols in neighboring decodable
   words; a second Viterbi decoding operation (redecoding) constrained
   to follow only paths consistent with the known symbols from
   previously decodable Reed-Solomon codewords; and a second Reed-
   Solomon decoding operation using the output from the Viterbi
   redecoder and additional erasure declarations to the extent possible.
   It is estimated that this code and decoder can achieve a decoded bit
   error rate of 1 x 10(exp 7) at a concatenated code signal-to-noise
   ratio of 0.76 dB. By comparison, a threshold of 1.17 dB is required
   for a baseline coding system consisting of the same (14,1/4)
   convolutional code, a (255,223) Reed-Solomon code with constant
   redundancy 32 also interleaved to depth 8, a one-pass Viterbi
   decoder, and a Reed Solomon decoder incapable of declaring or
   utilizing erasures. The relative gain of the enhanced system is thus
   0.41 dB. It is predicted from analysis based on an assumption of
   infinite interleaving that the coding gain could be further improved
   by approximately 0.2 dB if four stages of Viterbi decoding and four
   levels of Reed-Solomon redundancy are permitted. Confirmation of this
   effect and specification of the optimum four-level redundancy profile
   for depth-8 interleaving is currently being done. Author (revised)
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From karn@qualcomm.com Thu Jan 12 18:40:15 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSa3p-00018qC; Thu, 12 Jan 95 18:40 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id QAA15580; Thu, 12 Jan 1995 16:42:12 -0800
Date: Thu, 12 Jan 1995 16:42:12 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501130042.QAA15580@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <2428@k5yfw.ampr.org>
Subject: Re: [HFSIG:174] Re: HF modulation

>        Boy does the signal ever sound like noise...as you tune across
>        the signal the S meter will rise and fall and you will think you
>        are just tuning a noisy frequency.

A year or so ago somebody on the cypherpunks list came up with the
following wonderful adaptation of Clarke's famous saying that "any
sufficiently advanced technology is indistinguishable from magic":

"Any sufficiently advanced communication is indistiguishable from noise".

This is actually implied by Shannon's theory. The more efficient a
modulation/coding method is, the more noiselike it must become.  The
reverse is not necessarily true (just because it's noiselike doesn't
mean it's efficient).

Phil

From karn@qualcomm.com Fri Jan 13 15:58:32 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rSu0q-0000UZC; Fri, 13 Jan 95 15:58 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id OAA25848; Fri, 13 Jan 1995 14:00:25 -0800
Date: Fri, 13 Jan 1995 14:00:25 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501132200.OAA25848@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <D60CDC50F6D@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:193] Re: HF Modulation

>Taking these observations into account, as I have indicated in my earlier 
>posting - an appropiate convolutional coder or the right type of block 
>code was equally effective on parallel tone modems. This reseach was done 
>prior to soft-decision coding becoming popular and I am sure other advances 
>were made in coding theory since. 

Soft-decision decoding wins especially big on fading channels, by the
way.  As I mentioned in my discussion, convolutional decoding is much
more easily adapted to soft decision decoding. It's almost universal
in Viterbi decoding, somewhat less so in sequential because of its
greater sensitivity to gain errors.

Soft decision decoding can be adapted to block codes, but with
considerably greater difficulty. The technique is called "Chasing
bits", after David Chase, the inventor. Basically, you determine your
N weakest received symbols. Then you try decoding all 2^N possible
values of these weak symbols (for a binary code) along with the
"strong" received symbols. Take each decoded block, re-encode it and
pick the result that's closest in Hamming distance to the original
received block of symbols.

Obviously the complexity goes up exponentially with N. That can really
stress your block decoding software.

Non-binary codes like Reed Solomon codes can be "softened" somewhat by
simply erasing your weakest symbols. Since a RS code can correct twice
as many symbol erasures as errors, you stand an improved chance of
decoding the block correctly.

Erasure decoding on a binary channel can be seen as soft-decision
decoding with only 3 symbol values: "1", "0" and "unknown". A little
"softness" goes a long way; just adding an erasure indication is a big
win, especially on deep fading channels. In my experiments with rate
1/2 sequential Fano decoding, I found I could barely handle 8-9%
symbol errors on a hard-decision binary channel. But if I introduced
erasures rather than errors, I could tolerate nearly 50% erasures.

One way to implement erasure decoding even when you don't have a
3-level channel is to send a packet twice and compare the two. You
erase any symbols that don't match.

Phil
From FORRERJ@frl.orst.edu Fri Jan 13 22:37:27 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rT0Es-0001YgC; Fri, 13 Jan 95 22:37 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id NAA20885 for <hfsig@tapr.org>; Fri, 13 Jan 1995 13:15:10 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 13 Jan 95 20:35:23 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 13 Jan 95 20:35:22 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 13 Jan 1995 20:35:15 PST8PDT
Subject:       Re: [HFSIG:204] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <D9C90023B27@frl.orst.edu>

Hi Phil,

I have been making good progress with the parallel DSP modem - a few tricks 
on the tone generation and it actually now sounds a little musical, 
perhaps a little warbly - this is an 8 channel version that fits into 250 Hz 
and has a raw bit rate of 1000 bps - At the moment I'm testing things by 
running the the modem in full duplex with loopback.

Phil has been making excellent contributions on coding methods - in 
addition, we also have to start discussing the data link layer in all 
seriousness. I would suggest that the first attempt be at a simple FEC 
method but are open to any suggestions? 


73's

Johan, KC7WW




From frode@dxcern.cern.ch  Wed Jan 18 09:28:39 1995
Return-Path: <frode@dxcern.cern.ch>
Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rUcJA-0000ExC; Wed, 18 Jan 95 09:28 CST
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA17517; Wed, 18 Jan 1995 16:28:19 +0100
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA25255; Wed, 18 Jan 1995 16:28:16 +0100
From: frode@dxcern.cern.ch (Frode Weierud)
Message-Id: <9501181528.AA25255@dxcern.cern.ch>
Subject: Re: [HFSIG:205] Re: HF Modulation
To: hfsig@tapr.org
Date: Wed, 18 Jan 1995 16:28:15 +0100 (MET)
In-Reply-To: <D9C90023B27@frl.orst.edu> from "Johan Forrer                                                                             FL" at Jan 13, 95 10:44:00 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1400      



Hi all,

> I have been making good progress with the parallel DSP modem - a few tricks 
> on the tone generation and it actually now sounds a little musical, 
> perhaps a little warbly - this is an 8 channel version that fits into 250 Hz 
> and has a raw bit rate of 1000 bps - At the moment I'm testing things by 
> running the the modem in full duplex with loopback.

> Phil has been making excellent contributions on coding methods - in 
> addition, we also have to start discussing the data link layer in all 
> seriousness. I would suggest that the first attempt be at a simple FEC 
> method but are open to any suggestions? 

It appears to be that fragments of code are growing in several
corners of the HFSIG list, such as Johan's channel simulator code,
Johan's DSP code for the MIL-STD-188-110A parallel tone modem and
Phil's code for the Viterbi algorithm.

I for one would like very much to have a peek at this code to play
around a bit, get my hands 'dirty' and get some experience. Would
it be possible to arrange an Anonymous FTP server somewhere where
the list members could dump their code, data files, documents etc.
and where we all can have easy access. I agree that lot of the code
will be experimental and not in a form fit for public distribution,
but on a UNIX host it is very easy to arrange for a hidden directory
to house our not yet consumer ready code.

73 Frode, LA2RL
From FORRERJ@frl.orst.edu Wed Jan 18 10:56:54 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rUdgh-00019GC; Wed, 18 Jan 95 10:56 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA06939 for <hfsig@tapr.org>; Wed, 18 Jan 1995 01:34:22 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 18 Jan 95 8:54:46 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 18 Jan 95 8:54:36 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 18 Jan 1995 08:54:34 PST8PDT
Subject:       Re: [HFSIG:206] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E08E528710B@frl.orst.edu>

Hi Frode,

<some lines deleted>

>
>It appears to be that fragments of code are growing in several
>corners of the HFSIG list, such as Johan's channel simulator code,
>Johan's DSP code for the MIL-STD-188-110A parallel tone modem and
>Phil's code for the Viterbi algorithm.
>
>I for one would like very much to have a peek at this code to play
>around a bit, get my hands 'dirty' and get some experience. Would
>it be possible to arrange an Anonymous FTP server somewhere where
>the list members could dump their code, data files, documents etc.
>and where we all can have easy access. I agree that lot of the code
>will be experimental and not in a form fit for public distribution,
>but on a UNIX host it is very easy to arrange for a hidden directory
>to house our not yet consumer ready code.
>
>73 Frode, LA2RL

Thanks for bringing this up - Greg suggested we use tcet.unt.edu in 
the mean time and I checked and found that there indeed was a TAPR
subdirectory. I am not sure what the future plans are for a permanent home
for these code fragments.

The bits and pieces that I have is rather experimental and at this stage
would like to hang on a bit before placing it on an anonymous ftp site.
However, I have been sharing the source code with whoever asked for it,
at least I can warn them ahead of time of what they are in for. Please
feel free to request the code. 

I have a "C" version of the HF channel simulator as well as the beginnings 
of a DSP version for the sound card DSP. The "C" simulation of the OFDM 
modem is probably the easiest to understand and allows you to modify it
to your liking. The DSP version is more involved as it has to deal with
optimized stuff like the radix-4 FFT and multitone signal synthesis. You
would also need the sound card and the ADI development tools to do any 
work on it. I also have several programs that deal with Golay(24,12),
Reed-Solomon, and BCH block codes.

Phil promised that he would be making his convolutional coding program
available after doing some cleanup work. I am quite interested in trying
that with the OFDM modem.

I also suggest looking at Eric's OFDM simulations - it is very enlightening.

73's

Johan, KC7WW
From gjones@tenet.edu Wed Jan 18 16:28:16 1995
Return-Path: <gjones@tenet.edu>
Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rUirA-0000UfC; Wed, 18 Jan 95 16:28 CST
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id QAA09979 for hfsig@tapr.org; Wed, 18 Jan 1995 16:27:57 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199501182227.QAA09979@Alice-Thurman.tenet.edu>
Subject: Re: [HFSIG:207] Re: HF Modulation
To: hfsig@tapr.org
Date: Wed, 18 Jan 1995 16:27:56 -0600 (CST)
In-Reply-To: <E08E528710B@frl.orst.edu> from "Johan Forrer                                                                             FL" at Jan 18, 95 11:13:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 737       

According to Johan Forrer                                                                             FL:
> Thanks for bringing this up - Greg suggested we use tcet.unt.edu in 
> the mean time and I checked and found that there indeed was a TAPR
> subdirectory. I am not sure what the future plans are for a permanent home
> for these code fragments.

ftp.tapr.org should be registered as a mx record later today and should be
availble for access shortly, once the it distributed fully (figure a few
days).

HF SIG will have a location for this type of thing. I'll let you know when
we I think it is all operational.  Johan will get a special login so that you
can manage the area.

/tapr/SIG/hfsig

Should be better than TCET :-)

Greg
From bm@lynx.ve3jf.ampr.org  Wed Jan 18 20:08:18 1995
Return-Path: <bm@lynx.ve3jf.ampr.org>
Received: from hydra.carleton.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rUmIH-0000dtC; Wed, 18 Jan 95 20:08 CST
Received: from lynx.ve3jf.ampr.org (root@lynx.ve3jf.ampr.org [44.135.96.100]) by hydra.carleton.ca (8.6.9/8.6.9) with SMTP id VAA22916 for <hfsig@tapr.org>; Wed, 18 Jan 1995 21:08:03 -0500
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14)
	id m0rUmI3-0002hbC; Thu, 19 Jan 95 02:07 GMT
Message-Id: <m0rUmI3-0002hbC@lynx.ve3jf.ampr.org>
From: bm@lynx.ve3jf.ampr.org (Barry McLarnon VE3JF)
Subject: Re: HF modulation
To: hfsig@tapr.org
Date: Thu, 19 Jan 1995 02:07:56 +0000 (GMT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 9052      

[I sent this a few days ago, but it seems to have vanished in
cyberspace... I guess because of the listserver changeover.  Try, try
again... ]

I only tuned into this mailing list quite recently, so I'm just starting
to catch up on some of the discussions.  This message caught my eye:

> Phil's intriguing proposal for using M-ary orthogonal FSK
> with Walsh functions.  Over Christmas break (I'm pursuing
> an MSEE; if only I could catch it) I did some crude
> simulations of Phil's scheme using MATLAB.
> 
> First, I generated a 64x64 Hadamard matrix (whose rows are
> Walsh functions).  Then I generated 64 equal amplitude
> sinusoids, each separated by 32 Hz, from 512 Hz to 2528 Hz.
> I then picked a row at random from the Hadamard matrix to
> determine which sinusoids to sum together.  I sampled the
> time sequence at 32 kHz and plotted it over a full period
> of the combined signal.
> 
> I used several different Walsh functions to get a feel for
> the general behavior of these signals.  Since I started with
> 64 tones, and only 1/2 are on for any particular Walsh
> function, I was combining 32 separate tones.  The results
> were rather interesting, and very similar to Johan's.
> 
> Thus wrote Johan, KC7WW:
> 
> > As a way to learn more about how OFDM works for the
> > 39-tone MIL-STD-188 parallel modem, I wrote a C program
> > that simulates 39 parallel tones and combines them into
> > a single output signal.
> 
> [snip]
> 
> > I also did capture the simulated output waveform and was
> > quite concerned after inspecting the plot  -  the
> > presence of large spikes of significant magnitude (in
> > some cases, some 10-15 dB over the RMS value).
> 
> My simulation produced signals with peak-to-RMS ratios of
> 9 dB, they were generally of low amplitude except where
> the sinusoids came into phase and produced a large peak,
> and they generally looked 'noiselike'.  I also noticed that
> the signal's peak amplitude was not symetric about the time
> axis.  The signals had zero average value but the largest
> positive-going peak was twice as high as the largest
> negative-going peak.

Are you sure about the 9 dB?  A 32-tone signal should have a peak-to-RMS
ratio (aka "Crest Factor") of 18 dB for the case in which all of the
tones have zero initial phase shift.  The formula for the Crest Factor for
N tones is:

CF = sqrt(2N), or in dB, 20 log CF.
 
> As several others have noted, this high peak-to-RMS ratio
> will limit the amount of energy per symbol.  A signal such
> as this is potential trouble in any amplifier unless care is
> taken to control the peak level.  The asymetry in peak
> heights may furthur limit the amount of power an amplifier
> could deliver.  This is definitely not a constant envelope
> signal so linear amplifiers are in order.  As more tones are
> added the signals will have larger peak-to-RMS ratios.  This
> is consistent with Johan's observations since he was summing
> more tones.
> 
> The FCC limits amateurs based on PEAK envelope power (PEP),
> not RMS power.  As Phil noted, coding gains can buy back
> most of the loss in energy per symbol caused by the low RMS
> value of the signal, but it's still a significant limitation.
> Disregarding interference, it's ultimately the energy per
> bit that determines the performance of a digital system.
> 
> Phil's proposal was for a noncoherent system, which got me
> thinking (scary, eh?).  A noncoherent system ignores the
> phase of a signal; so, we have a free parameter to play with.
> My initial simulation started each sinusoid at zero phase.
> If we could use the phase to reduce the peak value of the
> signal we could get more energy per symbol and get the coding
> gain as well.
> 
> First I tried a linear shift in the initial phase across all
> 64 sinusoids.  I started with zero initial phase at the lowest
> frequency and increased the phase linearly to two pi at the
> highest frequency.  This resulted in signals with about the
> same peak-to-RMS ratios (8.25 dB), still 'noiselike', but the
> amplitude peaks became symetrical about the time axis
> (interesting and unexpected).

According to the reference I have (see end of this message), the CF
remains at sqrt(2N) in the case of phase shifts which vary linearly with
frequency, so it should still be 18 dB.
 
> My next attempt was to assign a random initial phase to
> each of the 64 sinusoids. The initial phase was distributed
> uniformly between zero and two pi.  This produced signals with
> an average peak-to-RMS ratio of 4.75 dB, the signals looked
> extremely 'noiselike', and the amplitude peaks were nearly
> symetrical.  Progress!

I think this is again off by a factor of two, but it illustrates that
random phase is certainly a better choice... in this case, the
dependency of CF on N is of the order of sqrt(log N) instead of sqrt(N).
 
> These were just the first ways I thought of to change the
> phase, there was no method to my maddness.  Even a naive
> method like ramdomizing the phase produced a 4 dB reduction
> in the peak-to-RMS ratio.  These results lead to a conjecture
> and several questions.
> 
> My conjecture is that we can reduce the peak-to-RMS ratio
> further, and maybe even approximate a constant envelope
> signal, by properly choosing the phases of the sinusoids.
> I think this is plausible since a wideband FM signal is a
> constant envelope signal and its spectrum looks like a set
> of nearly equal amplitude sinusoids, within a limited
> bandwidth.  I doubt we could get a truly constant envelope
> signal because we are using a small set of harmonically
> related sinusoids.

Your conjecture is correct. :-)
 
> Some questions I have:
> 
>    -  Are there systematic methods for choosing the
>       initial phases of the sinusoids to minimize the
>       peak-to-RMS ratio?

Yes.  See the paper by Boyd referenced below.  A proof exists that, in
the case where N is a power of 2, a set of phases can be found which
yields a Crest Factor of under 6 dB for arbitrarily large N.  Moreover,
he gives a procedure for selecting phases which yields a CF of about 4.6
dB for *any* N (except when N is very small).  The waveform generated by
this procedure is fascinating: it closely resembles a chirp signal (constant
envelope swept frequency, sometimes used as a spread spectrum technique).
 
>    -  What limits are there on reducing the peak-to-RMS
>       ratio?

According to Boyd, there is evidence that the ultimate limit is around 3
dB, but no systematic method for finding the phases exists (yet).  A
colleague of mine did some work a few years back on numerical methods
for finding near-optimum phases for multitone modems.  He used an
example of a 12-tone FSK modem (i.e., 12 simulaneous narrow-shift FSK
signals with regular frequency spacing - one of the CCIR standards) and
was able to find phase choices which yielded a CF in the 4-5 dB range
for all 4096 possible frequency combinations.  This would be a
considerable improvement over the 13.8 dB CF you'd get with linear
phases.
 
>    -  Are these limits, if they exist, related to the
>       number of sinusoids or the Walsh function used?

The limits seem to be independent of N, as long as N exceeds some
minimum number (of the order of 10-20).
 
>    -  Is this a well-known (or obscure) problem that
>       already has a solution?

It's on the obscure side, but certainly some work has been done.  I
haven't been involved in HF data comms for quite a few years, so I don't
know what recent advances might have been made in multitone modems...
but I can ask around a bit.
 
>    -  Is reducing the peak-to-RMS ratio really as
>       important as I seem to think it is?

I'd say it's certainly worth further investigation... with the processing
power now available in DSP's, control of the CF seems a lot more
feasible than it used to be.  Sometimes higher average power will buy
you an improvement in BER, and sometimes it won't (when you've hit an
irreducible error rate due to intersymbol interference from multipath),
but overall it would be a win.
 
> The MIL-STD modems apparently use PSK on the tones as well.
> Since the phase of any particular sinusoid in my simulation
> was constant over the symbol period this should allow using
> methods such as DPSK on the tones if someone wants to add an
> additional layer of modulation.  Would this increase the
> peak-to-RMS ratio?

I'm pretty sure it would, since you're now putting an additional
constraint on the phases.  If you want to Keep It Simple, stick with
noncoherent FSK (which generally works at least as well as DPSK in
multitone HF modems anyway).

References:

S. Boyd, "Multitone signals with low crest factor", IEEE Trans. on
Circuits and Systems, vol. CAS-33, no. 10, October 1986, pp. 1018-1022.

S. Shlien, "Minimization of the Peak Amplitude of a Waveform", _Signal
Processing_, vol. 14, no. 1, January 1988, pp. 91-93.
 
> Eric, N2NNP

Barry

-- 
Barry McLarnon  VE3JF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group
Email: bm@hydra.carleton.ca  or bm@lynx.ve3jf.ampr.org
From FORRERJ@frl.orst.edu Thu Jan 19 11:40:05 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rV0q2-0000FuC; Thu, 19 Jan 95 11:40 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA14305 for <hfsig@tapr.org>; Thu, 19 Jan 1995 02:18:00 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 19 Jan 95 9:38:26 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 19 Jan 95 9:38:04 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 19 Jan 1995 09:38:03 PST8PDT
Subject:       Re: [HFSIG:209] Re: HF modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E219F550CBF@frl.orst.edu>

Barry McLarnon  VE3JF/VA3TCP wrote:


> [I sent this a few days ago, but it seems to have vanished in
> cyberspace... I guess because of the listserver changeover.  Try, try
> again... ]


This appears to happen occasionally - please just keep trying. 


> I only tuned into this mailing list quite recently, so I'm just starting
> to catch up on some of the discussions.  This message caught my eye:

<...lines deleted...>


Welcome aboard Barry - looking forward to your contributions.


73's

Johan, KC7WW
 
From BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com Thu Jan 19 13:04:53 1995
Return-Path: <BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com>
Received: from hp.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rV2A6-00018CC; Thu, 19 Jan 95 13:04 CST
Received: from opnmail3.corp.hp.com by hp.com with SMTP
	(1.37.109.14/15.5+ECS 3.3) id AA003142285; Thu, 19 Jan 1995 11:04:45 -0800
Received: from  by opnmail3.corp.hp.com with SMTP
	(1.37.109.8/15.5+ECS 3.3) id AA01912; Thu, 19 Jan 1995 11:04:44 -0800
From: BLOOM_ALAN/HP5300_R0@opnmail3.corp.hp.com
X-Openmail-Hops: 2
Date: Thu, 19 Jan 95 11:04:00 -0800
Message-Id: <d0eHfbY000000000@MHS>
Subject: [HFSIG:209] Re: HF modulation
To: hfsig@tapr.org

Barry McLarnon VE3JF (bm@lynx.ve3jf,ampr.org) wrote:

>> My simulation produced signals with peak-to-RMS ratios of
>> 9 dB, ...

>Are you sure about the 9 dB?  A 32-tone signal should have a peak-to-RMS
>ratio (aka "Crest Factor") of 18 dB for the case in which all of the
>tones have zero initial phase shift.  The formula for the Crest Factor for
>N tones is:

>CF = sqrt(2N), or in dB, 20 log CF.

Note that this is the ratio of the peak power at the top of the sine wave(s)
to the total RMS power.  The PEP to RMS ratio will be 3 dB lower.

Even a single pure sine wave has a peak-to-RMS ratio of 3 dB.

AL N1AL
From chbrain@dircon.co.uk  Thu Jan 19 13:44:10 1995
Return-Path: <chbrain@dircon.co.uk>
Received: from felix.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rV2lr-00016YC; Thu, 19 Jan 95 13:43 CST
Received: by felix.dircon.co.uk id AA24765
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 19 Jan 1995 19:44:07 GMT
Date: Thu, 19 Jan 1995 19:44:07 GMT
Message-Id: <199501191944.AA24765@felix.dircon.co.uk>
Received: from aa006.pool.dircon.co.uk(193.128.228.6) by amnesiac via smap (V1.3)
	id sma024754; Thu Jan 19 19:43:47 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.3b4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: 8ary FEK modem

Hi all,
 Just b4 xmas I started trying to do a bit of DSP programming on a TMS320C50
DSK.
 I thought I would try to write an 8 ary modem a la MIL-STD 188-141A. I am using
a 10 Khz sample rate (mainly because all the ALE tones are multiples of 250Hz)
and I use the sample rate to generate the 8ms pulse periods table lookups etc. 
 Well the Golay coding / triple redundancy and tone generation seems to work
fine.
 However my idea of using 8 iir bandpass filters seems to have been a total
disaster! Mainly as I can only use 2nd order filters in the available time. 
 I had thought of using Goertzels algorithm commonly used in DTMF decoder
algorithms, but from what I have read 8ms doesn't seem to be long enough to
decode the tones.
 I could use an FFT I guess, but how do I get bit synchronisation? What ever
method I use I need to get bit sync.
 Anyone got any ideas on how best to synchronise and decode these tones?

Excuse my ignorance but this is the first DSP application I have tried to write.

By the way Phil thanks for the Specs, I got them last week, maybe after I get
this working I will start on them next!!

Regards Charles G4GUO
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From FORRERJ@frl.orst.edu Thu Jan 19 21:02:30 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rV9cI-0000iZC; Thu, 19 Jan 95 21:02 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id LAA18421 for <hfsig@tapr.org>; Thu, 19 Jan 1995 11:40:24 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 19 Jan 95 19:00:51 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 19 Jan 95 19:00:33 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 19 Jan 1995 19:00:26 PST8PDT
Subject:       Re: [HFSIG:212] 8ary FEK modem
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E2AFF881204@frl.orst.edu>

Hi Charles,

Well thats excellent work! I think you will find this an interesting 
excersise.

If you are looking for some good placed to read about this: Look at J.D. 
Ralph's book on Piccolo that was mentioned a while ago. There are a lot to 
gain about how to perform sync. Another good one in the paper by Chadwick 
and Springett in IEEE Trans. Comm Vol 18(#6) December 1970 " The design of 
a low data rate MFSK communication system". They mention two commonly used 
techniques.

Just a warning about the TI320C50 (applies to the 320C2x as well): beware 
of the REP instruction. If you use that in code that is of any substantial 
time, it can lock out interrupts. The idea in all this stuff is to plan to 
break your code into smaller chunks, some that can be performed in non-time 
critical and others that need to be time critical. Then write a fast, small 
real-time kernel to glue it all together.

It is often possible to operate a demodulator in non-coherent mode, then let 
your protocol analyser help you achive bit sync, and once you have that, 
close the loop to operate in synchrnous mode. This is what we do with both .

Anyway, IIR filters are bad news for many reasons - unless you have good 
practical experience - better leave them alone.

I dont know whether this helps.

Good Luck and keep us posted.


73's Johan KC7WW
From karn@qualcomm.com Thu Jan 19 22:02:16 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVAY9-00009WC; Thu, 19 Jan 95 22:02 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id TAA23822; Thu, 19 Jan 1995 19:54:09 -0800
Date: Thu, 19 Jan 1995 19:54:09 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501200354.TAA23822@servo.qualcomm.com>
To: esilbaug@afit.af.mil
CC: hfsig@tapr.org
In-reply-to: <199501071810.AA08932@stealth.afit.af.mil> (message from Eric E Silbaugh on Sat, 7 Jan 95 12:16 CST)
Subject: Re: [HFSIG:183] Re: HF modulation

Eric has demonstrated a fairly fundamental and powerful principle of
statistics: the central limit theorem. That is, if you sum up enough
independent random variables, eventually you get something that
approximates a normally (Gaussian) distributed random variable.

It doesn't really matter what the input distributions are, although if
the distributions are really non-gaussian it might take more of them
to approach a gaussian sum.

The peak-to-average power ratio of a gaussian is of course infinite,
so you have to pick some maximum level (corresponding to some number
of standard deviations past the norm) and set your amplifier to clip
there. If it's high enough, the lost energy will be negligible.

Phil
From karn@qualcomm.com Thu Jan 19 22:03:59 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVAZo-0001CbC; Thu, 19 Jan 95 22:03 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA23827; Thu, 19 Jan 1995 20:05:08 -0800
Date: Thu, 19 Jan 1995 20:05:08 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501200405.UAA23827@servo.qualcomm.com>
To: larry@owrlakh.unbc.edu
CC: hfsig@tapr.org
In-reply-to: <199501072204.OAA02948@owrlakh.unbc.edu> (message from Larry Gadallah on Sat, 7 Jan 95 16:13 CST)
Subject: Walsh functions reference

I don't have any references offhand, but they're easy to describe.

A Hademard matrix:

	is symmetric
	is square
	has a dimension that's a power of 2
	is composed of only 0s and 1s
	is defined recursively as follows:

	Hn+1 =	|Hn	 Hn|
		|Hn	~Hn|

	
	with, by definition, H0 = |0|

So if you apply this rule, you get

	H1 =	0	0
		0	1

	H2 =	0	0	0	0
		0	1	0	1
		0	0	1	1
		0	1	1	0

and so forth.

A Walsh function is simply a row (or column) taken from a Hademard matrix.

The interesting thing to note about the rows of a Hademard matrix is that
they're mutually orthogonal. That is, if you pick any two rows at random,
you'll find that the number of columns in which the two rows agree is equal
to the number of columns in which they disagree.

Also, except for the first row, each row has an equal number of 0s and
1s.

One of the earliest uses for these things was to set up wire crossing
plans for old open-wire telephone lines to minimize crosstalk. Very
clever.

Phil



From karn@qualcomm.com Fri Jan 20 00:17:37 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVCf8-0001PDC; Fri, 20 Jan 95 00:17 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id WAA23928; Thu, 19 Jan 1995 22:14:49 -0800
Date: Thu, 19 Jan 1995 22:14:49 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501200614.WAA23928@servo.qualcomm.com>
To: shall@rain.org
CC: hfsig@tapr.org
In-reply-to: <Pine.SUN.3.90.950109085422.1092A-100000@coyote.rain.org> (message from Stephen Hall on Mon, 9 Jan 95 11:05 CST)
Subject: Re: [HFSIG:187] Re: G-TOR Booklet

>Rolf, Regarding G-TOR: I attended a talk given by Phil Anderson regarding
>G-TOR vs. Pactor and it appeared that G-TOR has much more powerful error
>correction than Pactor.  I would be interested in your evaluation after
>you have had an opportunity to check it out. Steve, WM6P

Indeed it does. As I understand it, pactor has *no* error
correction. All it does is accumulate bit energy across multiple
transmissions of the same packet. This does increase Eb/N0 and hence
the chance of decoding a packet correctly, but it is much better to
encode the data first to get some power gain as well as the Eb/N0 increase.

To quantify things, simply sending the same packet twice and then
combining transmissions increases Eb/N0 by 3 dB. Encoding the packet
in a strong rate 1/2 soft-decision-decoded convolutional code and then
sending the result in two transmissions not only increases the Eb/N0
by 3 dB, but also provides up to 7 or 8 dB of coding gain, for a total
improvement of 10-11 dB.

G-TOR also uses a Type II Hybrid ARQ/FEC protocol, which I've been
advocating for some time because of its ability to combine the best of
FEC (ability to deal with rotten channels) with the best of ARQ
(adaptability to rapidly changing channel conditions).

Unfortunately, G-TOR uses a relatively weak code (Golay) and as far as
I know does hard decision decoding. So the coding gain isn't as great
as it could be; I think it's only a couple of dB.

Phil


From rs@ife.ee.ethz.ch Fri Jan 20 01:23:49 1995
Return-Path: <rs@ife.ee.ethz.ch>
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVDhB-00014qC; Fri, 20 Jan 95 01:23 CST
Received: from ife (actually ife-etz.ethz.ch) by bernina.ethz.ch 
          with SMTP inbound; Fri, 20 Jan 1995 08:23:23 +0100
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Message-Id: <9501200723.AA04434@ife>
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA04434;
          Fri, 20 Jan 1995 08:23:22 +0100
Received: by gillespie.ethz.ch; Fri, 20 Jan 95 08:23:21 +0100
Subject: Re: [HFSIG:216] Re: G-TOR Booklet
To: hfsig@tapr.org
Date: Fri, 20 Jan 95 8:23:20 MET
In-Reply-To: <199501200614.WAA23928@servo.qualcomm.com>; from "Phil Karn" at Jan 20, 95 12:20 am
content-length: 2041

> ...As I understand it, pactor has *no* error
> correction. All it does is accumulate bit energy across multiple
> transmissions of the same packet.

Yes, this is correct; Pactor uses a simple Memory-ARQ protocol without
any error-correction coding (i.e. it is not a hybrid protocol at all).


> G-TOR also uses a Type II Hybrid ARQ/FEC protocol, which I've been
> advocating for some time because of its ability to combine the best of
> FEC (ability to deal with rotten channels) with the best of ARQ
> (adaptability to rapidly changing channel conditions).
> 
> Unfortunately, G-TOR uses a relatively weak code (Golay) and as far as
> I know does hard decision decoding. So the coding gain isn't as great
> as it could be; I think it's only a couple of dB.

I was involved in developing an HF-modem over the last 4 years
or so. Unfortunately it never made it to the market :-(
It employed such an adaptive Memory Type II Hybrid ARQ/FEC protocol on top of 
a constant-envelope offset QPSK modulation. The memory-ARQ was augemented by
a kind of Chase' code-combining using convolutional-codes for error-correction.
Indeed, this modem allowed us to adapt over a wide range of signal-to-noise
ratios and achieved still some bit/s throughput at an SNR of -20 dB (measured at
3 kHz bandwidth), whereas all other modems I tested stop working at around -9 dB.
So this confirms Phil's estimate of a 10-11 dB gain.


The GTOR booklet should be on its way to HB9...

73,
Rolf
-- 
                                --- * * * ---

Rolf Sommerhalder                             
Swiss Federal Institute of Technology (ETH)   home address:
Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
Gloriastrasse 35                              Wermatswilerstrasse 96
8092 Zurich / Switzerland                     8610 Uster / Switzerland

Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81

From FORRERJ@frl.orst.edu Fri Jan 20 11:12:33 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVMsv-0000oPC; Fri, 20 Jan 95 11:12 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA20903 for <hfsig@tapr.org>; Fri, 20 Jan 1995 01:50:24 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 20 Jan 95 9:10:52 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 20 Jan 95 9:10:29 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 20 Jan 1995 09:10:22 PST8PDT
Subject:       Re: [HFSIG:214] Re: HF modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E392A520687@frl.orst.edu>

Hi All,

As I gain more working experince with these composite audio signals, I 
don't think we should, as Phil suggested, break our heads too much about 
the poor crest factor. In my 8-channel system, I scaled the RMS value way 
down so that the dynamic range of the D/A can gandle the peaks. Playing the 
audio through the speaker amp, it sounds quite clean - nothing adverse to 
report at all. Actually, if one look at a sound clip on the Windows sound 
editor, it also shows some poor crest factor - though thats quite normal 
for everyday sounds.

Now here is the challenge for you technical types: Could someone (Al, 
Barry) explain what it would take in terms of linear amps etc, to be able 
to use this waveform, i.e. if one say have the rms level set at 1W output, 
and expect some 18 dB peaks, what should the RF amp have to deliver to pass 
the peaks. I know its simple math, but just for everyones curiosity. Thanks 
fellows.

73's

Johan, KC7WW
From kchen@apple.com Fri Jan 20 12:09:36 1995
Return-Path: <kchen@apple.com>
Received: from apple.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVNm2-0000HNC; Fri, 20 Jan 95 12:09 CST
Received: by apple.com (5.61/8-Oct-1993-eef)
	id AA08031; Fri, 20 Jan 95 10:08:46 -0800
	for hfsig@tapr.org
Date: Fri, 20 Jan 95 10:08:46 -0800
From: Kok Chen <kchen@apple.com>
Message-Id: <9501201808.AA08031@apple.com>
To: hfsig@tapr.org
Subject: Hadamard matrices

Just a small correction on Phil's posting.  Hadamard is spelled with
an "a" after the "d," not an "e."

Also, Hadamard matrices do not have to be a power of 2.  The neccessary
condition is that the order is 2, or a multiple of 4.  Not all multiples
of 4 can exist.  The first number where the condition is insufficient is
order 188.  See Berlekamp's Algebraic Coding Theory book for a discussion.
(McGraw-Hill, 1968 - my copy predates the ISBN numbering, sorry).

One of the nice properties of Hadamard matrices which Phil did not mention
is that the inverse of a Hadamard matrix is its own transpose scaled by
the order of the matrix. This makes taking the inverse transform as easy
as doing the forward transform.

(Hadamard is more well known for the "Hadamard Inequality" regarding the
relationship between the determinant of a square matrix and the square
magnitude of its elements.)

See Robert McEliece, "The Theory of Information and Coding," Addison
Wesley, 1977, ISBN 0-201-13502-7 for a reference to the fact that the 
best block codes with a certain distance property are all related to 
the Hadamard matrix.

Finally, I'm not sure which came first - Rademacher-Walsh functions or
Hadamard matrices.  Both Walsh and Hadamard were contemporaries during
the early 1900s.  I need to ask some mathematician friends about that.


73

Kok Chen, AA6TY				kchen@apple.com
Apple Computer, Inc.
From karn@qualcomm.com Fri Jan 20 16:33:27 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVRtU-0000SGC; Fri, 20 Jan 95 16:33 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id OAA03393; Fri, 20 Jan 1995 14:35:24 -0800
Date: Fri, 20 Jan 1995 14:35:24 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501202235.OAA03393@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <9501200723.AA04434@ife> (message from Rolf Sommerhalder on Fri, 20 Jan 95 01:39 CST)
Subject: Re: [HFSIG:217] Re: G-TOR Booklet

I just checked my references. Hard decision Extended Golay (24,12)
over a BPSK or QPSK AWGN channel has a gain of about 2.5 dB at
BER=1e-5. As expected, soft decision decoding buys another 2dB for a
total of 4.5dB.

Convolutional codes can do much better at the same rate of 1/2. K=7
soft Viterbi decoded can give about 5.5-6.0 dB, and going to K=9 gives
6.0-6.5dB.  (All at a BER of 1e-5). K=32 soft Fano (sequential)
decoded gives about 7-7.5 dB of gain.

Phil
From FORRERJ@frl.orst.edu Fri Jan 20 19:03:42 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVUEu-00018uC; Fri, 20 Jan 95 19:03 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id JAA24576 for <hfsig@tapr.org>; Fri, 20 Jan 1995 09:41:34 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 20 Jan 95 17:02:03 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 20 Jan 95 17:01:44 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 20 Jan 1995 17:01:40 PST8PDT
Subject:       Re: [HFSIG:220] Re: G-TOR Booklet
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E41053C7F24@frl.orst.edu>

Hi Phil,

Those figures for coding gain on Golay that you mentioned, does it account 
for interleaving? In the Pierce paper they show that an effective 
constraint factor, i.e. high order of interleaving, in the order of 5000 - 
50000 bits, used with the perfect codes (23,12,3) (Golay) and (127,64,10) 
works as well as any of the convolutional codes they tested, including 
concatenated convoltutional - block codes. What am I missing - are these 
figures of merit apples and oranges? HELP!

Could you also perhaps give us some feedback on what kind of resolution 
would you need on the soft decision decoding (how many levels) would be 
practical, i.e. 16 bits would produce a very large trellis would'nt it? Is 
4 levels sufficient?

Keep up the good work.

73's

Johan, KC7WW
From karn@qualcomm.com Fri Jan 20 20:40:21 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVVkQ-0001L2C; Fri, 20 Jan 95 20:40 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA03627; Fri, 20 Jan 1995 18:42:24 -0800
Date: Fri, 20 Jan 1995 18:42:24 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501210242.SAA03627@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <E41053C7F24@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:221] Re: G-TOR Booklet

>Those figures for coding gain on Golay that you mentioned, does it account 
>for interleaving? In the Pierce paper they show that an effective 

Interleaving is a no-op on the AWGN channel. The error distribution is
already uniformly random, so interleaving doesn't make any difference.

Of course, HF is *not* an AWGN channel. So interleaving can make a big
difference there, as it does on the mobile fading channel.

Also, when you concatenate codes the channel seen by the outer code is
decidedly non-AWGN even if the physical channel seen by the inner code
is AWGN.  For example, Voyager used Reed-Solomon over Viterbi, and
Viterbi decoding errors generally occur in characteristic bursts until
the decoder eventually resettles on the correct path through the
trellis. Interleaving spread out these bursts over multiple RS blocks,
making them easier to correct.

Phil
From FORRERJ@frl.orst.edu Sat Jan 21 15:34:50 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rVnSI-000045C; Sat, 21 Jan 95 15:34 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id GAA27134 for <HFSIG@tapr.org>; Sat, 21 Jan 1995 06:12:38 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Sat, 21 Jan 95 13:33:09 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Sat, 21 Jan 95 13:32:55 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Sat, 21 Jan 1995 13:32:50 PST8PDT
Subject:       Eval copy of parallel modem
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E558AE51424@frl.orst.edu>

Hi folks,

I will place an evaluation copy of the parallel modem on the net on
monday. The modem runs in real time on a PSA sound card - I have tested it 
on my Orchid Soundwave32 and will also test it on a Cardinal card over the 
weekend.

This is only a test setup but I am sure you will find it interesting. The 
PC host sends a test message over the 8-channel OFDM modem that runs on 
the DSP on the sound card and plays the demodulated message as received 
from the modem, on the screen. You will hear the tones going over the 
speaker and see the rate that it writes to the screen. This version 
occupies only 250 Hz, so you could multiply things by four to get a felling 
of what is coming, of course it will be slower once we add the error-
correcting code.


The next task is to work on the synchroniser and then the data-link layer. 
Then we will be able to start testing over the air. 

I dont have FTP capability here from home, else would have put it on the 
net already. Look for the code monday at ftp.ucsd.edu in 
/hamradio/packet/tcpip/incoming/pmodem1.zip
I will include a short readme to help you set it up and run it.

73's

Johan, KC7WW

From rs@ife.ee.ethz.ch Mon Jan 23 01:10:13 1995
Return-Path: <rs@ife.ee.ethz.ch>
Received: from bernina.ethz.ch by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWIuf-00009VC; Mon, 23 Jan 95 01:10 CST
Received: from ife (actually ife-etz.ethz.ch) by bernina.ethz.ch 
          with SMTP inbound; Mon, 23 Jan 1995 08:10:02 +0100
From: Rolf Sommerhalder <rs@ife.ee.ethz.ch>
Message-Id: <9501230710.AA05321@ife>
Received: from ife.ee.ethz.ch (gillespie) by ife.ee.ethz.ch id AA05321;
          Mon, 23 Jan 1995 08:10:00 +0100
Received: by gillespie.ethz.ch; Mon, 23 Jan 95 08:09:59 +0100
Subject: Re: [HFSIG:221] Re: G-TOR Booklet
To: hfsig@tapr.org
Date: Mon, 23 Jan 95 8:09:59 MET
In-Reply-To: <E41053C7F24@frl.orst.edu>; from "Johan Forrer FL" at Jan 20, 95 7:06 pm
content-length: 1659

Johan wrote:
> Could you also perhaps give us some feedback on what kind of resolution 
> would you need on the soft decision decoding (how many levels) would be 
> practical, i.e. 16 bits would produce a very large trellis would'nt it? Is 
> 4 levels sufficient?

I should dig out a reference about this question which provides you with
exact graphs how much you loose/gain by decreasing/increasing the number
of quantization levels.
My own experience is that 256 level quantization (i.e. 8 bit) is fine, but
8 level quantization still works and the losses (versus 256 level quantization)
are around 1/8 to 1/4 dB (if I recall thouse figures correctly). However,
the performance of a 8 level quantized Viterbi decoder is heavily dependend
on the correct setting of the quantization thresholds/levels, i.e. a
perfectly adapted AGC is a must. The more quanitzation levels you spend
in the decoder, the looser your gain control may be.

73,
Rolf

P.S. Most of the commercial Viterbi decoder chips available work with 3-bit
(plus additional erasure symbol) or 3.5- or 4-bit quantization.

-- 
                                --- * * * ---

Rolf Sommerhalder                             
Swiss Federal Institute of Technology (ETH)   home address:
Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
Gloriastrasse 35                              Wermatswilerstrasse 96
8092 Zurich / Switzerland                     8610 Uster / Switzerland

Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
E-Mail rolf.sommerhalder@ife.ee.ethz.ch       Swiss Disaster Relief HBK81

From FORRERJ@frl.orst.edu Mon Jan 23 11:03:05 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWSAQ-0000sbC; Mon, 23 Jan 95 11:03 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA00382 for <hfsig@tapr.org>; Mon, 23 Jan 1995 01:42:17 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 23 Jan 95 9:00:52 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 23 Jan 95 9:00:25 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 23 Jan 1995 09:00:23 PST8PDT
Subject:       Re: [HFSIG:217] Re: G-TOR Booklet
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E8101787ACB@frl.orst.edu>

Rolf Sommerhalder wrote:

<...lines deleted...>

> I was involved in developing an HF-modem over the last 4 years
> or so. Unfortunately it never made it to the market :-(
> It employed such an adaptive Memory Type II Hybrid ARQ/FEC protocol on 
top of 
> a constant-envelope offset QPSK modulation. The memory-ARQ was augemented 
by
> a kind of Chase' code-combining using convolutional-codes for error-
correction.
> Indeed, this modem allowed us to adapt over a wide range of signal-to-
noise
> ratios and achieved still some bit/s throughput at an SNR of -20 dB 
(measured at
> 3 kHz bandwidth), whereas all other modems I tested stop working at 
around -9 dB.
> So this confirms Phil's estimate of a 10-11 dB gain.


Sounds like a nice accomplishment - congratatulations! Have you though
about publishing something about it? I am sure we all would be very
interested learning more about it. OQPSK has a very nice and clean 
waveform - I will look into that a little more. What kind of DSP is
this work based on?

I have been using 16-bit soft-decoding Memory-ARQ on the sound card
implementation of Pactor and have found it to help quite a bit - a bit
better than nothing at all.
 
73's

Johan, KC7WW

From FORRERJ@frl.orst.edu Mon Jan 23 11:07:04 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWSEH-0001KqC; Mon, 23 Jan 95 11:07 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA00598 for <hfsig@tapr.org>; Mon, 23 Jan 1995 01:46:47 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 23 Jan 95 9:05:21 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 23 Jan 95 9:05:02 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 23 Jan 1995 09:04:52 PST8PDT
Subject:       Re: [HFSIG:223] Eval copy of parallel modem
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <E81152C3BC6@frl.orst.edu>

Hi all,

The files are now on ftp.ucsd.edu. 

I would like to thank OM Kok Chen, AA6TY for the wonderful
discussions we have had on how to make this parallel modem work.

73's

Johan, KC7WW

From esilbaug@afit.af.mil Mon Jan 23 16:55:18 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWXfH-0001MtC; Mon, 23 Jan 95 16:55 CST
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA28813
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 23 Jan 1995 17:53:53 -0500
Date: Mon, 23 Jan 1995 17:53:53 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501232253.AA28813@stealth.afit.af.mil>
To: bm@lynx.ve3jf.ampr.org
Subject: RE: HF Modulation
Cc: hfsig@tapr.org


Barry,

Thanks for the references!  They just added to my depression :)
Seriously, it's nice to see that my conjecture wasn't too far
off the mark.  They answer some of the questions I asked and
confirm that the problem is difficult.

In my simulations I was thinking in terms of power not voltage so
I used 10*log() not 20*log().  This is the source of the factor of
2 difference in our crest factor calculations.  I probably should
have been more specific; others were confused by this as well.

I tracked down the papers you mentioned and gave them a quick
reading.  Boyd considers a sum of equally spaced sinusoids and
Shlien considers a sum of sinusoids with arbitrary frequency
spacing (I think).  Our case seems to be in between with a set
of equally spaced sinusoids but not all are present.

It was encouraging to see that limits on crest factor reduction
are nearly independent of the number of sinusoids.  This means the
Walsh functions will control how well a particular set of phases
works.  I'm going to try the quadratic initial phase scheme from
the Boyd paper and see what it does.

Both authors found that using numerical methods to reduce the crest
factor is difficult because the minimizing function has many local
minima.  It seems possible to get significant reductions in the
crest factor, but there is no known optimal method.  The hopeful
note was Shlien's results showing that most of the local minima are
pretty good.

I am not familiar with the linear programming methods Shlien used.
What methods did your colleague use?

Thanks again for the answers, now I've got even more questions!

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From karn@qualcomm.com Mon Jan 23 22:34:29 1995
Return-Path: <karn@qualcomm.com>
Received: from servo.qualcomm.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWcxW-0001aAC; Mon, 23 Jan 95 22:34 CST
Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id UAA01968; Mon, 23 Jan 1995 20:36:36 -0800
Date: Mon, 23 Jan 1995 20:36:36 -0800
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199501240436.UAA01968@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <9501230710.AA05321@ife> (message from Rolf Sommerhalder on Mon, 23 Jan 95 01:24 CST)
Subject: Re: [HFSIG:224] Re: G-TOR Booklet

Rolf is quite right about most commercial Viterbi decoders using 3-bit
symbols (8 levels). Qualcomm's chips do this, and it seems to be
standard practice. It's enough to get you within a fraction of a dB of
the theoretical limit for infinite quantization.  The chip area you
save with narrower data paths can instead be spent on having more
add-compare-select units to allow longer constraint lengths, a net
performance gain.

Of course, in software there's no particular reason to use smaller
samples since you already have wide data paths in your CPU that you
might as well use.

Correct gain settings is important, but Viterbi decoders are
significantly more robust than sequential decoders in this
respect. Ideally you want to set your gains on noise alone for both
types of decoders, but real AGCs respond to the sum of signal plus
noise so the tracking isn't exact.

We (Qualcomm) have an ap note on this precise topic that derives the
correct gain setting as a function of noise and shows the degradation
in required Eb/N0 as a function of AGC error.  It's quite small for
about a 6dB range around the correct level, then rises rapidly outside
that.

Fortunately, due to the steepening of the waterfall curve with coding
you really only have to get the gain right at the nominal Eb/N0. A
weaker signal would be too weak to decode even with a correct gain,
and a strong signal will decode correctly even with a large gain
error.

I said that sequential decoders are less robust to gain
misadjustments. Much of the early literature (there's been a
noticeable dropoff in sequential decoding papers since the late 60s
when the Viterbi algorithm came out) talks about avoiding the problem
by using hard decision decoding. The long-constraint length (K>=32)
codes generally used in sequential decoding are so strong that they
make up for much of the 2dB you lose with hard decision coding.

But I don't want to give up that 2dB without a fight.  Getting soft
decision decoding to work really well in my protocol, especially with
non-Gaussian noise, may take some doing.

Phil


From esilbaug@afit.af.mil Tue Jan 24 08:08:31 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWluz-00010sC; Tue, 24 Jan 95 08:08 CST
Received: from dolphin.afit.af.mil by stealth.afit.af.mil with SMTP id AA08567
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 24 Jan 1995 09:08:23 -0500
Date: Tue, 24 Jan 1995 09:08:23 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501241408.AA08567@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: RE: HF Modulation


Barry,

Thanks for the references!  They just added to my depression :)
Seriously, it's nice to see that my conjecture wasn't too far
off the mark.  They answer some of the questions I asked and
confirm that the problem is difficult.

In my simulations I was thinking in terms of power not voltage so
I used 10*log() not 20*log().  This is the source of the factor of
2 difference in our crest factor calculations.  I probably should
have been more specific; others were confused by this as well.

I tracked down the papers you mentioned and gave them a quick
reading.  Boyd considers a sum of equally spaced sinusoids and
Shlien considers a sum of sinusoids with arbitrary frequency
spacing (I think).  Our case seems to be in between with a set
of equally spaced sinusoids but not all are present.

It was encouraging to see that limits on crest factor reduction
are nearly independent of the number of sinusoids.  This means the
Walsh functions will control how well a particular set of phases
works.  I'm going to try the quadratic initial phase scheme from
the Boyd paper and see what it does.

Both authors found that using numerical methods to reduce the crest
factor is difficult because the minimizing function has many local
minima.  It seems possible to get significant reductions in the
crest factor, but there is no known optimal method.  The hopeful
note was Shlien's results showing that most of the local minima are
pretty good.

I am not familiar with the linear programming methods Shlien used.
What methods did your colleague use?

Thanks again for the answers, now I've got even more questions!

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From muphaus@cris.com  Tue Jan 24 22:19:46 1995
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rWzCq-0000EaC; Tue, 24 Jan 95 22:19 CST
Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by voyager.cris.com (4.1/SMI-4.1)
	id AA22606; Tue, 24 Jan 95 23:18:58 EST
To: hfsig@tapr.org
Cc: forrerj@frl.orst.edu
From: muphaus@cris.com (Marv Uphaus)
Subject: Re: [HFSIG:223] Eval copy of parallel modem
Date: Tue, 24 Jan 1995 23:53:16 -0600
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <CTU9lCysSc7P077yn@cris.com>
In-Reply-To: <E558AE51424@frl.orst.edu>
Lines: 23

On Sat, 21 Jan 95 15:38 CST, "Johan Forrer FL" <FORRERJ@frl.orst.edu> wrote:

>I will place an evaluation copy of the parallel modem on the net on
>monday. The modem runs in real time on a PSA sound card - I have tested it
>on my Orchid Soundwave32 and will also test it on a Cardinal card over the
>weekend.

Johan, and All...

I FTPed the file and ran it and all I can say is keep going...  It looks 
(and sounds) good...  One note...  The SW32 has a load feature that allows 
you to load the driver...  Just do a "SW32 /F:parll.ld" and then run 
MODEM...

Johan, what are the clicks...  I distinctly hear tones but also some low 
frequency "clicks"...  Us novices want to know...  ;-)

--
Marv...

--  Marv Uphaus  --  muphaus@cris.com  --  Ph: 334-343-9256  --
--  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
--  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
From esilbaug@afit.af.mil Wed Jan 25 15:20:52 1995
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rXF8N-0000mIC; Wed, 25 Jan 95 15:20 CST
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA14845
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 25 Jan 1995 16:20:39 -0500
Date: Wed, 25 Jan 1995 16:20:39 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199501252120.AA14845@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: Crest Factor Control
Cc: esilbaug@afit.af.mil

This is a toothpaste commercial, NOT!



WHY CREST FACTOR CONTROL

Thus wrote Johan, KC7WW:

> Actually, if one look at a sound clip on the Windows sound editor, it
> also shows some poor crest factor - though  thats quite normal for
> everyday sounds.

Speech is well known as a 'peaky' (high crest factor) signal, thus the
voice processors (peak clipping) used by DXers.  The other extreme is
RTTY overheating a linear amp; higher average power.

Thus wrote Barry, VE3JF:

>>    -  Is reducing the peak-to-RMS ratio really as
>>       important as I seem to think it is?
>
> I'd say it's certainly worth further investigation... with the
> processing power now available in DSP's, control of the CF seems a lot
> more feasible than it used to be.  Sometimes higher average power will
> buy you an improvement in BER, and sometimes it won't (when you've hit
> an irreducible error rate due to intersymbol interference from
> multipath), but overall it would be a win.

Johan also enscribed:

> As I gain more working experince with these composite audio signals, I
> don't think we should, as Phil suggested, break our heads too much
> about the poor crest factor.

I have to agree.  High crest factors are not a 'show stopper' but will
make using multitone modems more difficult.  Likewise, low crest factors
will lower the peak instantaneous power which should reduce interference;
they are not a cure-all.

If we control the crest factor we can get more energy per symbol, for
the same input signal level.  Low crest factor signals will also reduce
the chances of accidentaly overdriving an amplifier.  This would make
the modem easier to use, which would be a real benefit.  How much more
energy and how much easier to use are open questions.

We need not worry about getting the absolute lowest crest factor;
instead, let's concentrate on controlling the crest factor to a
reasonable value.  In the paper Barry mentioned, Boyd was developing
multitone test equipment and notes that crest factors of 6 dB are
acceptable for many applications.  We can get a basic proof-of-concept
modem running, begin testing, and then refine it.


WHERE TO GO FROM HERE

Since we are talking about M-ary signaling it should be feasible to use
numerical or empirical methods to find sets of phases to minimize the
crest factor for each signal, as long as M is a reasonable number. Monte
Carlo methods will probably be useful (pun intended).

Looking towards an implementation, if we stay with incoherent
demodulation we may not have to standardize which phases to use.  Just
choose any set of phases giving reasonable crest factors; the magnitude
spectrum will be  unchanged.  It would be good to provide a standard set
so not everyone has to go through the minimization process.  Who knows,
there may be patterns which could lead to an empirical algorithm for
choosing a good set of phases; if not, we could use a look-up table to
set the initial phases. 

Johan sent me some information that suggests the crest factor may not be
preserved during SSB modulation.  This would not be good.  We must
ensure crest factor controlled signals are robust under SSB modulation,
and passband filtering distortions.  I will try to incorporate SSB
modulation into my simiulation and see what happens.


SIMULATIONS

Some late-breaking news on my MATLAB simulations of Phil's proposal for
using Walsh functions.  I implemented the method outlined in the Boyd
paper.  Basically, it involves putting a quadratic initial phase on each
sinusoid.  In other words, the first sinusoid has zero phase and the
initial phase of the other sinusoids increases as the square of the
distance, in frequency, from the first.

Using 20*log(peak/RMS), the crest factor for the zero phase case is 18
dB.  With quadratic initial phase the crest factor is between 7-8 dB.
Simulation of 20 different signals gave an average of 7.52 dB.  That's
10 dB less than the zero phase case and may be good enough!  Many of the
signals looked like chirp signals, just like the examples in the Boyd
paper.  In a few cases my naive random initial phase method produced a
slightly lower crest factor. This was very rare; in most cases the
random method was 1-2 dB higher.


ALMOST FINISHED

Multitone signaling, OFDM, is one of several solutions we should
evaluate.  From a system view it has some attractive features: multiple
tones combat selective fading caused by multipath, and M-ary signaling
reduces the effects of inter-symbol interference.  Channel coding to
correct errors and automatic power control will probably also be part
of any robust, low interference HF modem.  However, we can start simple
and add complexity only when necessary.

Eric, N2NNP


    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From FORRERJ@frl.orst.edu Mon Jan 30 11:18:47 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rYzkS-0000UeC; Mon, 30 Jan 95 11:18 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA10493 for <hfsig@tapr.org>; Mon, 30 Jan 1995 01:57:36 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 30 Jan 95 9:18:12 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 30 Jan 95 9:17:51 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 30 Jan 1995 09:17:47 PST8PDT
Subject:       Re: [HFSIG:231] Crest Factor Control
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8A5E586F7A@frl.orst.edu>

Eric Silbaugh wrote:

<...lines...deleted>


> Looking towards an implementation, if we stay with incoherent
> demodulation we may not have to standardize which phases to use.  Just
> choose any set of phases giving reasonable crest factors; the magnitude
> spectrum will be  unchanged.  It would be good to provide a standard set
> so not everyone has to go through the minimization process.  Who knows,
> there may be patterns which could lead to an empirical algorithm for
> choosing a good set of phases; if not, we could use a look-up table to
> set the initial phases. 


Good suggestion Eric - this looks like the way we should do it. 

I only wish that there was some solution for QPSK. It appears that 
offset PSK is one possibility, perhaps waveshaping similar to 
generate MSK waveforms - may help to produce a constant envelope? 
I will be playing with that idea a bit more when I get a bit of time.
Does anyone know how this is done on the Harris 39-tone modems?

73's

Johan - KC7WW
From FORRERJ@frl.orst.edu Mon Jan 30 18:02:50 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rZ63T-0000oqC; Mon, 30 Jan 95 18:02 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA13890 for <HFSIG@tapr.org>; Mon, 30 Jan 1995 08:42:04 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 30 Jan 95 16:02:45 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 30 Jan 95 16:02:22 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Mon, 30 Jan 1995 16:02:15 PST8PDT
Subject:       Packet software for sound card
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <911C7750DB@frl.orst.edu>

Hi All,

This does not really belong in the HFSIG - just for those interested.

I have put the HB9JNX sound card modem software on the "upload" directory.
This is Thomas Sailer's 1200 and 9600 (G3RUH compatible) DSP modems
for PSA sound cards. Assuming you know how to integrate such
software into one of the "NOS" flavors, things will make sense.

Tom also has a neat RTTY/AMTOR/Pactor package that uses the sound
card for his DSP modem - scalable tones, FFT display etc. I will upload 
that as well.

Thanks to Tom for making his software available.

73's

Johan, KC7WW
From muphaus@cris.com  Tue Jan 31 00:48:55 1995
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rZCOT-00005bC; Tue, 31 Jan 95 00:48 CST
Received: from voyager.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by voyager.cris.com (4.1/SMI-4.1)
	id AA17624; Tue, 31 Jan 95 01:48:02 EST
To: hfsig@tapr.org
From: muphaus@cris.com (Marv Uphaus)
Subject: Re: [HFSIG:233] Packet software for sound card
Date: Mon, 30 Jan 1995 22:24:34 -0600
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <2kRBlCysSgj3077yn@cris.com>
In-Reply-To: <911C7750DB@frl.orst.edu>
Lines: 28

On Mon, 30 Jan 95 18:06 CST, "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu> wrote:

>Tom also has a neat RTTY/AMTOR/Pactor package that uses the sound
>card for his DSP modem - scalable tones, FFT display etc. I will upload
>that as well.

I got Tom's software last week, Johan, and it seems to work quite well...
What it doesn't do is reset the PSA card back properly...  Nothing I could
do would set the PSA card back properly for WinDOZ...  It wouldn't reload
the VSW32.386 driver properly...  Only turning the computer off and back on
would reset the card...

Tom, are you reading this...???   Anybody know a fix for this or is it a
coding problem in the exit from the DSP software...  I do, of course, know
to reload the GENMID.LD driver...  That seemed to go OK, but WinDOZ would
never load the VSW32.386 driver until the computer was turned off and on
again...

>Thanks to Tom for making his software available.

You bet, Tom...  Nice...!!!

--
Marv...

--  Marv Uphaus  --  muphaus@cris.com  --  Ph: 334-343-9256  --
--  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
--  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
From FORRERJ@frl.orst.edu Tue Jan 31 10:40:49 1995
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.29.1 #5) id m0rZLdG-0000coC; Tue, 31 Jan 95 10:40 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA17018 for <hfsig@tapr.org>; Tue, 31 Jan 1995 01:20:04 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 31 Jan 95 8:40:44 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 31 Jan 95 8:40:28 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 31 Jan 1995 08:40:24 PST8PDT
Subject:       Re: [HFSIG:234] Re: Packet software for sound card
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <A1BF76523B@frl.orst.edu>

Hi Marv,

I have E-mailed to Tom and will post the new version in the upload area. 
Will let you know.

For those interested, I will post my spectral display program for the PSA 
cards in the upload area. It works, though is nothing fancy - just a 
passing milestone during the OFDM research. look for FFTSCOP.ZIP.

73's

Johan, KC7WW
